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I. INTRODUCTION 


As GENERAL 


There has been continuous progress in the development of computers over the 
past four decades. The results are more impressive by any measure in the state of 
hardware than in the state of software. From the beginning hardware developers have had 
a theoretical basis that comes from other sciences, like mathematics, physic, mechanics, 
etc. Also, the hardware developers borrowed and applied standard methods from other 
engineering disciplines for design and manufacturing. In contrast, software developers 
initially relied primarily upon human imagination, invention, and ingenuity. This lack of 
an engineering approach has produced legacy software applications that cannot be 
supported any longer. 

As the science of software development slowly evolved into a distinct engineering 
discipline, software engineers established the processes, the techniques and the rules that 
govern the development of software systems. 

The process to develop a software system usually consists of the following 
phases’: Requirements Analysis, Functional Specification, Architectural Design, 
Implementation and Evolution. In the nineties the object-oriented methodology has 
emerged as the most popular method because it supports the rule that can be described by 
the maxim, "reduce, reuse recycle". The object-oriented methodology increases 


efficiency, reduces development time and decreases the cost of software products. 


' Berzins and Lugi in their book "Software Engineering with Abstractions" 1990 chapter 1 p 6 about the 
Software Development Process 
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Software engineering has also changed the process of software evolution and 
maintenance. The old approach "to maintain a software system for sontad of time and 
then to replace it with an complete new system" when further evolution 1s not feasible is 
not an efficient solution. It is too costly to lose the assets that an existent and working 
system offers, including all the previous work that went into the requirements analysis 
phase. Also, users have verified the existent system over time and have gained 
knowledge about the system’s operations through years of maintenance and development. 
To be efficient, the evolution technique’ for an existent system must respect that the 
current system is valuable even though it is increasingly difficulty to extend. Therefore, 
the new approach must respect the assets of the old system and developers should salvage 
any useful parts from the old system and change only the parts that must be changed. 

The most common problem when re-engineering old systems 1s that they are not 
implemented according to modern, evolvable methods like the object-oriented design 
techniques; however, the developers can still use the requirements specification of the old 
systems ir the first phase of the redesign. So the designers must retrieve the requirements 
specification from the old system and document them with object-oriented techniques. In 
addition, the most effective approach to redesign is to implement a prototype. In this way, 
the designer can verify the correctness of the requirements specification and design 
through reviews with the customer. 

Current software engineering techniques are well supported by commercial-off- 
the-shelf (COTS) products. Today COTS products are increasingly important and highly 


economical tools for organizations to explore reengineering opportunities and strategies. 


The ultimate goal is to reengineer the old system using object-oriented techniques that 


allows the concurrent evolution of software via component-based development. 
B. MOTIVATION 


The TRADOC Analysis Center of Monterey, California plans to redesign and re- 
implement the Campaign Planning Exercises (CAMPEX) discussion war game. The 
CAMPEX? is a software system that was implemented by the Air War College to provide 
students the opportunity to test their understanding of strategy, leadership, international 
security, National Security Decision Memorandums (NSDM), General Purpose (GP) 
forces, unified commands, and joint fundamentals. The current version of the CAMPEX 
system consists of two modules, the "Deployment" and the "Employment". In the 
"Deployment" module the student deploys joint forces and in the "Employment" module 
he employs the forces. 

The CAMPEX system lifecycle began in 1986 and the current version (with ID 
8.9°) was released in 1994. Because CAMPEX is still used today, we can assume that it 
satisfies most requirements of the Air War College. Moreover, we can conclude that the 
system requirements and the algorithms and other functions of CAMPEX have been 
verified in practice, because the CAMPEX was developed, maintained, and used by Air 
War College personnel. CAMPEX was implemented in the Microsoft Basic Professional 


Development System Version 7.10, and the object-oriented techniques were not used for 


> Air War College in the CAMPEX User Manual 
> Air War College Source Code of CAMPEX last version 


S, 


its design. Also, a serious problem for further evolution of CAMPEX is the lack of 
documentation for any phase of its development. | 

An important constraint that must be satisfied when reengineering a current 
software system is the available hardware. Today the user has PC’s with greater 
processing power and data storage capacity that often operate on a high capacity network. 
The reengineering of CAMPEX must account for this computing environment. 

The final factor that must be considered when reengineering CAMPEX is the 
High Level Architecture (HLA) for distributed simulations. The U.S. Department of 
Defense DoD) mandates use of the HLA in new simulations and the retrofit of legacy 


simulations by 2001. 
Be OBJECTIVES 


This thesis describes the reengineering of the CAMPEX "Employment" Module 
using object-oriented techniques with respect to the current user’s needs in combination 
with the current available hardware. The secondary goal is preparation for High Level 
Architecture compliance should the user decide to distribute CAMPEX over the network. 

So the primary objectives of my work were twofold: 1) research in the area of the 
Distributed Objects Architectures and 2) analysis and redesign of the CAMPEX 
"Employment" module with object-oriented techniques and verify the design with a small 
prototype. The prototype must work in the Microsoft Windows environment and allows 


user to run some of the CAMPEX procedures through Internet. 


D. THESIS ORGANIZATION 


Chapter IT provides: 
background on Distributed Objects Architectures, 
high level requirements for the Distributed Components, 
a brief description of the partial and "complete" existent solutions in this area, 
the advantages and disadvantages of each solution, and 
the common characteristics and differences. 

Chapter III provides the requirements analysis and functional specification of 
CAMPEX Employment that results from reverse engineering the current version. The 
requirements analysis and functional specification are documented using Unified 
Modeling Language (UML) notation. 

Chapter IV describes the new design and architecture of the new CAMPEX using 
the UML methodology and notation. The existing CAMPEX algorithms and functions are 
the basis for the design of the object interactions because the Air War College has already 
verified them in practice. 

Chapter V presents the prototype implementation. The prototype is implemented 
with ACCESS-2000 and Visual Basic. Chapter V contains the basic database design, 
queries and forms. Moreover, this chapter offers a "User Manual" that allows the user to 
test and use the prototype easily. 

Chapter VI summarizes the key elements of the thesis, provides observations 
about the difficulties and lessons learned, and provides insights and recommendations for 
future work to apply the selected Distributed Objects Architecture and to re-implement 


the entire CAMPEX. 
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II. DISTRIBUTED COMPONENTS ARCHITECTURE 


A. THE PROBLEM DESCRIPTION 


Even after many years the state of the art and science in software development is 
not as satisfactory as that in hardware development. Different vendors have developed 
numerous remarkable applications using various methods, computer languages, and 
platforms. The exploitation of all these old applications in combination with new 
applications under development on different types and configured machines that run over 


Internet poses one of the biggest challenges in the software engineering today. 
B. REQUIREMENTS AND CONSTRAINTS 


This section addresses the high-level requirements and constraints to solve the 
problem posed in the previous section. First the object-oriented methodology for 
software implementation comprises a requirement for new applications and a constraint 
for existing applications. This general requirement’ is that 

e the applications must consist of components, 

e the components should be characterized by high cohesion and loose coupling, 

e the components should be developed in accordance with object-oriented 

principles (encapsulation, polymorphism and inheritance), and 


e the components should communicate through messages. 


* Reaz Hoque and Tarun Sharma in their book "WEB Components” 1998 chapter | p 7 what are the 
Distributed Objects 


The second requirement is to cross network boundaries. The new architecture 
must allow the users to utilize applications that consist of components that can be 
distributed on different machines on WANs or LANs. This requirement demands that the 
application access the network in standard ways and expand its address space to the entire 
network effectively. 

The third requirement is that the components should be programming language 
independent. That is, components that are developed in different programming languages 
be able to interoperate in a distributed system. At the same time the user must be able to 
choose a unique tool for the creation and the integration of these heterogeneous 
components. 

The fourth requirement 1s to cross the platform boundaries. The new architecture 
must allow the old legacy applications as well as the new ones to run on machines of 
different type or configuration. In other words, machines and their operating system 
should not block communication among the components of the distributed application. 

The fifth requirement is to satisfy the "reduce, reuse, recycle" dictum. This 
requires that the application be reusable as a whole or in parts (patterns, components or 
objects). The application must be designed so that it can be deployed in an environment 
with diminished resources and function in a reduced, but useful, capacity. Finally, it 
must provide components and design features that can be recycled for the production of 
new applications. 

The sixth and last requirement is that the application must offer a satisfactory 
level of performance and reliability. This constraint follows directly from the maxim to 


"reduce". "Reduce" excludes solutions that increase the implementation time and 
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complexity. This excludes many popular solutions that are used today. Examples include 
the 4GL languages with fat clients, the development of low Eve drivers and new 
network protocols for the crossing of network boundaries, and the use of different tools 
with each programming language for breaching the programming language barriers. 


A final constraint is that the new system should demand no new resources. 
c. DISTRIBUTED COMPONENTS SERVICES 


Today many vendors have software development solutions that seem to satisfy all 
these requirements. These solutions are variants of the Distributed Components Based 
Architecture. All the vendors contend that they have realized the early dream of the 
software community for distributed computing that properly uses all the capabilities of 
the current hardware. 

Distributed architectures must offer the following services’: 

® naming service to provide a mechanism for locating distributed components in 

a system, 

¢ monitor service to watch the whole system for correctness and alert if 

something wrong happens to an operator, 

e listening service to ensure that users of the distributed components have the 

appropriate privileges, 

e persistence mechanism to uniformly save, update, and restore an object’s state 


using a persistent data store, 


> SUN Microsystems in JINI Architecture Specification version 1.0.1 1999 about Distributed Components 
Services 
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® transaction support mechanism to ensure that a transaction is completed or 
aborted in its entirety whenever work is performed. (Typically a transaction 
defines an atomic unit of work in an enterprise system. A distributed 
transaction is a single unit of work that spans multiple computers. ) 

e security mechanisms to ensure that communication from authorized users to a 
distributed object is secure, 

® messaging support to provide an asynchronous programming model, as 
opposed to the typical request-reply model. (There are many types of 
applications that require messaging. An example is an application in which the 
client and server are required to run in different times.) 

e distributed services to automatically deallocate distributed objects when they 
are no longer being used by their clients, and 

e resource management to manage distributed objects in such a way as to 
maximize scalability and support a large number of clients interacting with a 


large number of distributed objects in short period of time. 
D. EXISTING PARTIAL SOLUTIONS 


Today there are many suggestions from different vendors. Some of these 
suggestions tackle the problem of the distributed computing by trying to satisfy all the 
requirements and others by trying primarily to satisfy an individual requirement. 

The following techniques suggest solutions for various requirements of the distributed 


computing problem: 
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The Remote Procedure Call Mechanism® satisfies the requirement to cross network 
boundaries. It is probably the most popular technique for crossing network barriers. At 
first sight it seems well suitable for distributed computing since it allows one 
application to make functions calls through the network. However, if we examine 
RPC deeper we find that RPC does not allow the objects to change state. Adding this 
capability has a very large performance cost. 

Sockets mechanisms’ are another way to cross network barriers. This solution has 
many advantages, but it usually demands low-level network programming. To be 
useful for distributed computing architectures this solution should offer network 
interfaces that hide all the unnecessary low level networking details. 

Interpreted Languages® can solve the problem of the crossing operating system (OS) 
boundaries. Since this kind of languages is not compiled to a specific binary format, 
they can be reused and run in source code format on multiple machines. The drawback 
of this solution is the lack of speed because interpreted code is typically hundreds of 
times slower than the compiled code; also, the interpeter may not exists for some 
platforms. 

Binary Compatibility Layers can be used to cross OS barriers. This solution provides a 
layer of code on top of the OS that runs binary files compiled for a different OS. This 
solution is feasible if binary compatibility layers exist for all the OS’s. One problem 


with this solution is that it demands a lot of work from programmers. Another 


© Gopalan Suresh Raj in his book "A Detailed Comparison of CORBA, DCOM and JAVA/JINI 
”Reaz Hogue and Tarun Sharma in their book "WEB Components" 1998 chapter | p.14 what are the 
Distributed Objects 
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problem is that most applications use more than one OS layer, so the OS vendor must 
construct a new binary compatibility layer every time another OS layer is used. 
Language Binding can cross language barriers. The biggest weakness of this 
technique is that users must learn how the solution works in different programming 
environment. Consequently, it is not standard and can delay the implementation 
process. 

Another way to cross language barriers is a development environment that can 
compile to multiple target platforms. But this solution has a big drawback too. It 


demands a binary distribution. 
Je EXISTING COMPLETE SOLUTIONS 


The previous section discussed the most common partial solutions for distributed 
computing and emphasized their drawbacks. This section describes standard complete 
solutions. 

The Distributed Component Object Model (DCOM) is Microsoft’s solution for 
distributed computing. DCOM treats the problem of the distributed components as two 
different subproblems. The first subproblem? is the component architecture that describes 
component packaging and cross language interoperability. The second sub-problem 1s 
communication among components over the network and support for remote method 
invocation. 


* Reaz Hoque and Tarun Sharma in their book "WEB Components” 1998 chapter 1 p 15 what are the 
Distributed Objects 


” Software Engineering Institute DCOM Architecture Overview, 10 Jan 97, p.2 by Ed Morris and Emil 
Litvak 
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COM, an ancestor of the DCOM and now a part of DCOM, allows inter-process 
communication. COM supports interoperability and reusability of distributed objects by 
allowing developers to build systems by assembling reusable components from different 
vendors. By applying COM to build systems from preexisting components developers 
hope to reap benefits like maintainability and adaptability. 

COM defines an application-programming interface (API) for creating 
components to use in custom applications and to allow components to interact. However, 
the interacting components must adhere to a binary structure specified by Niereeot AS 
long as they adhere to this binary structure, components written in different languages 
can interoperate. 

The DCOM extends the COM by allowing network-based component interaction. 
While COM processes can run on the same machine in different address spaces, the 
DCOM extension allows processes to be spread across a network. With DCOM, 
components operating on a variety of platforms can interact as long as DCOM is 
available within the environment. COM and DCOM represent "low-level" technology 
that allows components to interact. Microsoft provides two higher-level application 
services, OLE and ActiveX, which are built on top of COM and DCOM. OLE provides 
services such as object "linking" and "embedding" that are used in the creation of 
compound documents (documents generated from multiple tool sources). ActiveX allows 
components to be embedded in Web pages. 

COM 1s a binary compatibility specification and associated implementation that 
allows clients to invoke services provided by COM-compliant components (COM 
objects). As shown in Figure 1 services implemented by COM objects are exposed 
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through a set of interfaces that represent the only point of contact between the clients and 


the object. 





Figure 1. Client Using COM Object Through an Interface Pointer (Source: 
Software Engineering Institute DCOM Architecture Overview, 10 Jan 97, p.2.) 

COM defines a binary structure for the interface between the client and the object. 
This binary structure provides the basis for interoperability among software components 
written in arbitrary languages. As long as a compiler can reduce language structures 
down to this binary representation, the implementation language of the client is 
independent from the run-time binary representation of the object. Thus, COM objects 
and clients can be coded in any language that supports Microsoft’s COM binary structure. 

An interface provides a collection of related methods. COM objects and interfaces 
are specified using Microsoft Interface Definition Language (IDL), an extension of the 
DCE Interface Definition Language standard. To avoid name collisions, each object and 
interface must have a unique identifier. 

Every COM object runs within of a server. A single server can support multiple 
COM objects. There are three ways in which a client can access COM objects provided 


by a server: 
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Figure 2. Three Methods for Accessing COM Objects (Source: Software 
Engineering Institute DCOM Architecture Overview, 10 Jan 97, p.4.) 


e In-process server: The client can link to a library containing the server 
directly. The client and server execute in the same process. Communication is 
accomplished through function calls. 

e Local Object Proxy: The client can access a server running in a different 
process yet on the same machine through an inter-process communication 
mechanism. This mechanism is actually a lightweight Remote Procedure Call 


(RPC). 


e Remote Object Proxy: The client can access a remote server running on 
another machine. The network communication between Shon and server is 
accomplished through DCE RPC. The mechanism supporting access to remote 
servers 1s called DCOM. 

If the client and the server are in the same process, the sharing of data between 
them is simple. However, when the server process is separate from the client process, as 
in a local server or remote server, COM must format and bundle the data in order to share 
it. This process of preparing the data is called marshalling. Marshalling is accomplished 
through a "proxy" object and a "stub" object that handles the cross-process 
communication details for any particular interface. COM creates the "stub" in the object’s 
server process and has the stub manage to the real interface pointer. Then COM creates 
the "proxy" in the client’s process, and connects it to the stub. Then the proxy supplies the 
interface pointer to the client. 

The client calls the interfaces of the server through the proxy, which marshals the 
parameters and passes them to the server stub. The stub unmarshals the parameters and 
makes the actual call inside the server object. When the call is completed, the stub 
marshals return values and passes them to the proxy, which in turn returns them to the 
client. The same proxy/stub mechanism is used when the client and server are on 
different machines. However, the internal implementation of marshalling and 
unmarshalling differs depending on whether the client and server operate on the same 
machine (COM) or on different machines (DCOM). Given an IDL file, the Microsoft 
IDL compiler can create default proxy and stub code that performs all necessary 


marshalling and unmarshalling. 
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Figure 3. Cross-Process Communication in COM (Source: Software Engineering 
Institute DCOM Architecture Overview, 10 Jan 97, p.5.) 


All COM objects are registered with a component database. As shown in Figure 
4, when a client wishes to create and uses a COM object: 

e itinvokes the COM API to instantiate anew COM object, 

e COM locates the object implementation and initiates a server process for the 
object, 

e the server process creates the object and returns an interface pointer at the 
object, and then 

e the client can interact with the newly instantiated COM object through the 


interface pointer. 
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Figure 4. Creating a COM Object Pointer (Source: Software Engineering Institute 
DCOM Architecture Overview, 10 Jan 97, p.4.) 


COM includes interfaces and API functions that expose operating system services 
as well as other necessary mechanisms for a distributed environment such as naming and 
events. 

DCOM advantages are: 

e Microsoft supports DCOM so it already has many users. 

e DCOM and the other Microsoft tools for implementing components usually 

have a low price. 

e The components that DCOM integrates can be implemented in many 
programming languages so DCOM succeeds in crossing the language 
boundaries. 

e DCOM offers an interface that crosses network boundaries in a standard and 


simple way. 


e DCOM is a robust application. It is easy for the programmers to learn to use 
the DCOM (though one must be an expert in areas like distributed systems 
design, multi-threaded applications, and networking to implement an 
embedded system with DCOM). 

Disadvantages of DCOM are: 

e Once an interface is defined, it should not be changed. New methods should 
not be added and existing methods should not be modified. This interface 
restriction is not enforced, but it is a rule that component developers should 
follow. 

e DCOM depends on the Windows Operating System. This is its main 
disadvantage. DCOM does not satisfy the requirement for crossing platform 
boundaries. 

e Older legacy applications are not easy to integrate with a system that uses 
only Windows. 

e Because COM and DCOM are based on a native binary format, components 
written to these specifications are not really platform independent. 

e DCOM is not standard for many vendors. For example Netscape does not 
support Activex. 

e DCOM cannot guarantee high performance. 

e DCOM does not support security, but there are external packages for security 
support. 

e DCOM does not support applications with real-time requirements and cannot 


guarantee reliability to applications. 
Ke 


The Common Object Request Broker Architecture’? (CORBA) is the Object 
Management Group’s (OMG) solution. OMG is an industry group with over six hundred 
member companies representing computer manufacturers, independent software vendors, 
and a variety of government and academic organizations. CORBA is a consortium 
standard, not a "formal" IEEE, ANSI or ISO standard. 

The vision behind CORBA is that distributed systems are conceived and 
implemented as distributed objects. The interfaces to these objects are described in a 


high-level, architecture-neutral specification language that supports object-oriented 


design abstraction. CORBA supports distributed systems that feature rapid development, 


Application Objects 
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maintainability and adaptability. 
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Figure 5. CORBA Architecture Layers (Source: Software Engineering Institute 
CORBA Architecture Overview, 10 Jan 97, p.2.) 


Logically the CORBA consists of 4 layers (Figure 5): 

e The Object Request Broker (ORB) layer is the core of CORBA and it handles 
requests for objects. 

e The CORBA Common Object Services Layer or CORBAServices supplies 
the object support service. This layer is fundamental when building non-trivial 


distributed applications. These services currently include asynchronous event 


'° Kurt Wallnau in his technical paper “Common Object Request Broker Architecture" 
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management, transactions, persistence, externalization, concurrency, naming, 
relationships, and lifecycle management. 

CORBA Common Facilities Layer or CORBAFacilities has two sub-layers, 
the horizontal and the vertical. They may be useful for some distributed 
applications, but are not as universally applicable as CORBAServices. These 
facilities include user interface, information management, system 
management, task management, and a variety of "vertical market" facilities in 


domains such as manufacturing, distributed simulation, and accounting. 


The ApplicationObjects Layer is an extension of the vertical sub-layer of 


CORBAFacilities layer. Developers must implement this layer for their applications 


because CORBA offers no standard solution. 
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Figure 6. Detailed CORBA Architecture (Source: Software Engineering Institute 


CORBA Architecture Overview, 10 Jan 97, p.3.) 


ORB Core is the CORBA runtime infrastructure. The interface to the ORB Core 


is not defined by CORBA. It is proprietary to a particular vendor. ORB Interface is a 
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standard interface (defined in IDL) to functions provided by all CORBA-compliant 
ORBs. 

The IDL processor generates IDL stubs for each interface defined in IDL. Stubs 
hide the low-level networking details of object communication from the client while 
presenting a high-level, object type-specific application programming interface (API). 

Dynamic Invocation Interface (DII) is an alternative way for clients to access 
objects. While stubs provide an object type-specific API, DII provides a generic 
mechanism for constructing requests at run time. An interface repository allows some 
measure of type checking to ensure that a target object can support the request made by 
the client. 

Object Adaptor provides extensibility of CORBA-compliant ORBs to integrate 
alternative object technologies into the OMA. For example, adaptors may be developed 
to allow remote access to objects that are stored in an object-oriented database. Each 
CORBA-compliant ORB must support a specific object adaptor called the Basic Object 
Adaptor (BOA). The BOA defines a standard API implemented by all ORBs. 

IDL Skeletons'’ are the server-side analogue of IDL stubs. IDL skeletons receive 
requests for services from the object adaptor and call the appropriate operations in the 
object implementation. 

Dynamic Skeleton Interface (DSI) is the server-side analogue of the DII. While 


IDL skeletons invoke specific operations in the object implementation, DSI defers this 


'' Jason Pritchard in his book "COM and CORBA Side by Side” Jun 1999 p. 50 
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processing to the object implementation. This is useful for developing bridges and other 
mechanisms to support inter-ORB interoperation. 

Advantages of CORBA are: 

e CORBA is a standard architecture for Object Request Brokers. CORBA 
compliant vendors support portability and interoperability across different 
programming languages, hardware platforms, operating systems, and ORB 
implementations. 

e When combined with the Object Management Architecture, CORBA can 
result in distributed systems that can be rapidly developed and can reap the 
benefits of CORBA like maintainability and adaptability. 

e CORBA can cross network, operating systems and programming language 
boundaries. 

e CORBA can support with the current addition of Real-Time Event Service 
source and type base filtering, event correlations, real-time dispatching and 
UDP/IP multicast communication. Also with the addition of Scheduling 
Service, CORBA can support static rate monotonic scheduling and dynamic 
maximum urgency first scheduling to assign priorities and validate 
schedulability. These are services that have prevented CORBA from 
supporting real-time applications and guaranteeing high performance in the 
past. 

e CORBA makes the development of distributed applications easier than with 


previous technologies. 
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e CORBA is a mature product with a large and growing number of CORBA 
implementations available in the marketplace including implementations from 
most major computer manufacturers and independent software vendors. 

The disadvantages of CORBA are: 

e CORBA is a complex specification and considerable effort is required to 
develop expertise in its use. 

e CORBA ORB’ vary in prices from vendor to vendor and some ORB’s are 
very expensive. 

e There is no organization to test in a formal way all aspects of a CORBA 
implementation, so little information is available. 

e Changes to the CORBA specifications while technically justified have 
resulted in unstable ORB implementations. 

e IDL is the "“least-common denominator". It does not fully exploit the 
capabilities of programming languages especially in the definition of abstract 
data types. 

e CORBA specifies only a minimal range of security mechanisms; more 
ambitious and comprehensive mechanisms have not yet been adopted by the 
OMG. 

JINI is Sun Microsystems’ distributed computing solution. JINI is a distributed 
system that allows a group of computing devices connected by an Intranet or Internet to 
be used by a group of users as a single computer system. Technically JINI system extends 
the Java application environment from a single virtual machine to a network of machines. 


The JINI system is Java centric and assumes that all the co-operating components are 
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implemented in the Java programming language. It is, however, possible to accept 
components created in other languages if their compilers can produce J ag byte codes. 

The high level goals of JINI are: 

e Enabling users to share services and resources over the network. 

e Providing users easy access to resources anywhere on the network while 

allowing the user’s network location to change. 

e Simplifying the task of building, maintaining, and altering a network of 

devices, software and users 

The logical parts of JINI that try to satisfy these goals are: 

e A set of components that provides an infrastructure for federating services in a 

distributed system. 

e A programming model that supports and encourages the production of reliable 

distributed services. 

e Services that can be part of a federated JINI system and that offer 

functionality to any other member of the federation. 

JINI services are typically computation, storage, or communication with another 
service, which is a software filter, a hardware device, or another user. JINI programmers 
must think in terms of services when they think of a set of servers and clients, users and 
programs, and programs and files. Users, clients, servers do not exist in JINI; everything 
is a service. JINI systems provide mechanisms for service construction, lookup, 
communication and use in a distributed system. Examples of services include devices 
such as printers, displays, or disks, software applications or utilities, information such as 


databases and files, and users of the system. 
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Services in a JINI system communicate to each other using a service protocol 
which consists of interfaces written in the Java programming language. The set of such 
protocols is open-ended. The base JINI system defines a small number of such protocols 
to provide critical service interactions. 

The Lookup Service finds and resolves other services. This service is the main 
mechanism for the interaction between a user and a JINI system. Lookup Service's job is 
to know the available interfaces of the other services and the methods and functionality 
that the other services are able to offer. Thus, when a user requests a particular service the 
lookup service locates the appropriate service to satisfy the user. 

Java Remote Method Invocation (RMI) provides the communication among 
services. In reality it is not a service but an infrastructure that supports the 
communication among services. RMI provides mechanisms to find, activate, and garbage 
collect object groups. It provides remote procedures call mechanisms that allow not only 
the interchange of data among the objects, but also the interchange of whole objects 
including code for methods. 

JINI supports two levels of security. The first level determines if the user of the 
system who requests the service has the right to uSe this particular service. The second 
level checks if a service has the right to request another service; furthermore, the 
relationships among services are maintained 1n the access control list responsible for this 
second level of security. 

The access to many services in the JINI system environment is based on leasing. 
Leasing in JINI means that each object allocates a particular service for particular period 


of time using predefined rules. JINI offers two kinds of leasing service, exclusive leasing 
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that means no one else can use the service simultaneously and non-exclusive leasing that 
allows the reallocation of the same service at the same time from a different user or 
object. 

The JINI Transaction interfaces provide a service protocol to coordinate a two- 
phase commitment. A series of operations, either within a single service or spanning 
multiple services, can be wrapped in a transaction. The semantics of a transaction 1s left 
up to the service using those interfaces. 

The JINI architecture supports distributed events too. An object may allow other 
objects to register interest in events in the object and receive a notification of the 
occurrence of the event. This enables distributed event-based programs to be written with 
a variety of reliability and scalability guarantees. 

The components of the JINI system can be segmented into three categories 
infrastructure, programming model and services. 

Advantages of JINI are: 

e JINI can cross network and operating systems boundaries. 

e JINI has the best methodology for event handling for the communication 

between objects. 


e JINI is a simple technology because it only uses Java’s environment. 


ZY 


infrastructure Programming Model | Services 


Java VM Java APs JDL 

RMI Javea Beans ™ Enterprise Bears 
Java Security JTS 

DiscoveryfJan = | Leasing. Printing 

Distributed Security | Trarsactons Transaction Manager 
Lookup Events JayaSpaces™ Service 


Figure 7. JINI Architecture Segmentation (Source: SUN Microsystems Inc. JINI 


Architecture Specification, Jan 1999, p.12.) 
In JINI it is easy, natural and often automatic for occurrences to join and leave 
the system. 
JINI systems are currently far more dynamic than other network groups which 
must be configured by hand in a centralized fashion. 
The model can recognize that the delivery of a distributed notification may be 
delayed. 
The event and notification interfaces, which are an extension of the event 
model used by JavaBeans components to the distributed environment, enable 


event-based communication among JINI services. 


The disadvantages of JINI are: 


The JINI architecture gains most of its simplicity by assuming that the Java 
programming language is the implementation language for components. 

One cannot cross language boundaries with JINI and most legacy applications 
are not written in Java so they must be rewritten before we can reuse them 


with JINI. 
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e JINI is a very new architecture and nobody has ever used it extensively in the 


real world yet, so it is not mature enough. 
he COMPARISON AMONG THREE ARCHITECTURES 


There is no way to provide a complete comparison among these three distributed 
computing systems. Any comparison depends on the purpose of the comparison and the 
background of the audience. 

Parallels among the main operations of the CORBA, DCOM and JINI include 
these: 

All three support multiple object instantiation, the CORBA and JINI through 
registration and skeleton instantiation, and DCOM by the server explicitly or dynamically 
through the COM run-time system. 

DCOM uses the Object Remote Procedure Call (ORPC), CORBA the Internet 
Inter-ORB Protocol! (IOP), and JINI the RMI as their underlying remote protocols. 

When a client object needs to activate a server object, DCOM can do it by a 
method call; on the other hand CORBA offers the same service through naming or trader 
service, and JINI through a lookup service. 

For object handling the client for DCOM uses an interface pointer while CORBA 
and JINI use the object reference. 

The Registry in DCOM maps object names as does the Implementation 


Repository in CORBA, and the RMJRegistry in JINI. 
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The type information for methods is held by Type Library in DCOM, by Interface 
Repository in CORBA, by the object itself in JINI which can be queried by using 
reflection and introspection. 

The responsibility for an object’s location and activation falls to Service Control 
Management (SCM) with DCOM, to Object Request Broker (ORB) for locating and to 
Object Adapters for activating with CORBA, and to Lookup Service with JINI. 

So we can see that the three systems have very similar operations. Other 
similarities are: 

e They have complex ways to define the interface of their components. 

e They require that the user know networking to set up remote services. 

e They can cross the network boundaries. 

e They offer a low level of security. 

CORBA is the most complete of the three. First, it is independent of language 
and operating system. JINI can support only components that are implemented with Java 
and DCOM works properly only in a Windows OS environment. Second, CORBA with 
the addition of real-time event service and scheduling can be reliable enough and can 
offer satisfactory performance. JINI may equal CORBA in this regard, but DCOM does 
not. Third, CORBA is mature enough. Many applications have already been implemented 
with it. DCOM is also mature, but JINI is not. CORBA is an open standard. JIN} will be 
offered as part of JAVA and DCOM as part of Windows. Of course, CORBA is not the 
perfect solution for implementers of a distributed component system because of the high 


level of effort and training required for success. 
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HI. SOFTWARE REQUIREMENTS SPECIFICATION 


A. OVERVIEW 


The purpose of this project is to redesign and re-implement the CAMPEX 
Employment Module with a distributed architecture using the object-oriented 
methodology. The final product must offer to the Air University of United States Air 
Force a tool that allows students to improve their skills in air campaign design through 
practice. Also, this software must allow students to execute exercises from their personal 


computers and transfer the results of their practice to the war college server. 


B. CUSTOMERS 


The customers are resident students, nonresident students and instructors at the 


Air University. 


c: GOALS 


The ultimate goal is to offer an application to Air War College students that 
allows them to execute exersices in air campaign planning. This application will also 
allow instructors at the Air University to check the students’ results. This application 
must be capable of running on the students personal computers as well as on the Air 
University computers. Thus, the CAMPEX Employment Module must offer: 

e Fast and easy downloading. 

e Fast and easy installation on computers that runs Microsoft Windows 


Operating System independent of the configuration of the students’ machines. 
Sil 


Selection of the tactical exercise scenario. 

Cues to the user for correctly sequencing events. 
Information to the user about necessary assumptions used during the exercise. 
Creation and editing of air tasking orders (ATQs). 

Planning of the missions. 

Automatic update of the game state with the execution of a game cycle. 
Creation of reports with the results and estimations. 

The ability to return to a previous state. 

Display of the map of the exercise area. 

Analysis of the student’s plan. 


Printing of reports, results, and information lists. 


USER CHARACTERISTICS 


The typical user of the CAMPEX Employment Module requires special education 


in the air campaign planning. In addition, the user is expected to have a medium or low 


level of familiarity with the Windows operating system and the Internet. If the user has 


these characteristics then, he will be able to use the module after a brief training session 


that will take approximately two to three hours. 


GENERAL CONSTRAINTS 


The CAMPEX Employment Module must be a fully autonomous system capable 


of functioning for extended periods of time with minimal support. The CAMPEX 


prototype will be provided in an ACCESS-2000 runtime-software package that will 
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include all the required bindings. This CAMPEX Employment Module will depend on 


the Windows Operating system and Microsoft Office commercial product. 
F. ASSUMPTIONS AND DEPENDENCIES 


The following assumptions and dependencies have been defined in order to 
simplify the analysis of the CAMPEX Employment Module and the implementation of 
the CAMPEX Employment Module prototype. 

1. The user (student) must know how to operate a personal computer and more 
specifically how to use a personal computer that runs Microsoft Windows 
operating system. 

2. In this initial phase only the employment module prototype will be 
implemented. 

3. The software application will fully support the basic functionality of the 
CAMPEX Employment Module and partially support the optional 
functionality. 

4. The user must be connected to the Internet to execute the "Send Exercise" 


function. 
G. SYSTEM FUNCTIONS 
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Student Support Functions 


Creates and displays new Student Card 


Stores new Student attributes into the hidden 


objects repository (database) 
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Displays current student’s attributes 
Logs attributes changes to a student's object 
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Changes the object student attributes 


R1.7 Searches student objects instantiations with | U1 hidden 
input key 


2 [Send sere Fein 
Queries Exercises objects with input key 


Outputs the collected exercise attributes to 
evident 
the success of the process 








Air University database 


Displays message that informs student for 


Sel Retrieves the "Copyright Screen" from 


database 


R3.2 Displays the "Copyright Screen" 





R3.3 Retrieves the "Execute Order" from hidden 


database 


Displays the "Execute Order" 


ees Provides inter-process communication U3 evident 
Retrieves the "DIA Intel Update" from U3 hidden 
database Sees 


R3.8 Retrieves record the "Thai Forces U3 hidden 
Available" from database 





R3 Starts a CAMPEX module (Employment) 
Functions 
ez 





R3.6 








34 


_ Function — 


‘Use Case Category | 









pU3—— [evident evident 
Retrieves the “Weather Report" from hidden 
database i 
. <2 evident 
a Retrieves the "Navy Update" from database 
(U3 f evident 
Retrieves the "Weapon Availability Update" —_ cool 


from database 


R3. RBIS Displays the "Weapon Availability Update" (U3 fevident 


oe Nia record of "Program Notes" from isi 
database 


os the of "Bomb Damages —— 
Assessment and Targets Definitions" from 

database 

Displays the "Bomb Damages Assessment evident 
and Targets Definitions” ss 
Retrieves the "Analysis and Corrections" hidden 
from database —— 


R3. R321 Displays the "Analysis and Corrections" (U3 | evident 


—- the "Read me file for a 
U3 evident 
Module" text 


Initiates anew ATO object with the name evident 
given by user 
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Module" from database 









Displays the "Read me file for Employment 
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Copy an existent ATO toanew one witha |U5 | evident 
name given by user 


Displays an ATO enter form to enter ATO U4 evident 
attributes 


Support Planning Missions Functions 
Enters a target to the priority list 


Decreases the priority of the existed targets | U6 evident 
with lower priority than the specified 

priority by one 

Increases the priority of the existed targets U6 evident 
with higher priority than the specified 

priority by one 


R5.4 Deletes the targets with priority lower than — ee 


evident 
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R5.9 Search Missions objects with input key U7 hidden 
(mission or package) 


R5.10 Deletes a Mission object 
Fly an ATO Support Functions 


nn 
Executes the assigned missions and U8 hidden 
Collects all assigned missions, packages, U8 hidden 
and actual data objects er 


Calculates the collected objects 
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R6.5 Save the calculation’s results as attributes of | U8 id 
the new ATO state 


Initial Information Support Functions 
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re [ insignis [tn 


SST. Queries database for the necessary for U9 ‘hidden 
analysis objects 


Displays the missions’ analysis U9 fevident 


R7.9 Queries the database for Ground Forces a? 
objects 


mere) Displays the collected by the queries objects 
[Sy Estimated Results Support Functions ——— 
Queries database for Recce by target 


































R8.2 Displays Recce by targets for the current U10 evident 
program state 
R8.2.1 Queries database for missions and actual 







U10 hidden 
information objects 


Calculates the collected objects 


Displays estimated results of planned 
U10 hidden 
attribute sorties = empty 
= Displays missions without sorties 


missions before the missions execution 






Queries database for missions that have the 









| Use Case Case | Category” 


a =o. 
hidden 
create daily summary 


Displays daily summaries by Aircraft Type 
R8.10 Displays daily summaries by Task Type a 


R8.11 Queries database for necessary objects U10 hidden 
attributes to create the "logistics 
requirements" 
Calculates the results of the (R8.11) queries | U10 hidden 
to create the report i as 
Displays logistics requirements by Blue evident 
Base and Supply category = 
[eta Rss Spor Fats 
Ko! Queries database for necessary objects to hidden 
create "the cumulative summary report" ar 
R9.2 Calculates the collected objects attributes of | U11 hidden 
Ko.5 Displays cumulative summary withtheend | U1] evident 
of past date a | 


R9.4 Queries database for the necessary objects hidden 
for the report "Recce Targets at the start of 
the current Date" 


R9.5 Calculates the results of query (R9.5) 


Displays Recce for Targets at the start of the | U1] evident 
current date inl 
Queries the database for the necessary hidden 
objects to create the report "Enemy Planes 

over Blue Bases during the Past Day" 





_ Function ‘ak 





Oneres aiapate for necessary apiece to 





calculates the "daily summary" 






Calculates the queries (R8.7) results to 

























oo SRef# os. — »~ Function SS ss se Case | Category 
R9.8 G@nicilates ite Shik of query RO. 7) hidden 


Displays the number of enemy planes over evident 


“7 
hidden 
al =e 
Loe 


Roel Calculates the results of query (R9.10) 


Displays overall indicators of sorties at the evident 
end of the past date 


Queries the database for the necessary U11 hidden 
objects to create the report of "Overall 

Indicators of Effort Weight at the End of the 

Past Date " 


Ull | hidden 
Displays overall indicators of effort weight hidden 
at the end of the past date =o 
Queries the database for the necessary hidden 
objects to create the report of "Overall 
Indicators of Blue Attrition at the End of the 
Past Date" 


R9.18 Displays overall indicators of Blue Attrition 


R9.19 one hidden 
Past Date " 


R9.20 Calculates the results of query (R9.19) 
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the Blue Bases during the past date 






Queries the database for the necessary 
objects to create the report of "Overall 


Indicators of Sorties at the end of the Past 









at the end of the past date 


Queries the database for the necessary 







objects to create the report of "Overall 


Indicators of Loss Ratio at the End of the 











Ref# ™ gene Function | | | Use Case | Category : 
R921 : Displays ear indicators of loss a at Ull Brdent | 
7 the end of the past date | 
eee Queries the database for the necessary 





objects to create the report of "Losses by 






Mission and by Task Type During the Past 






Date" 


: 


- 
Displays losses by mission and by task type | U11 evident 
during the past date 


Queries the database for the necessary U11 hidden 


Calculates the results of query (R9.22) 






objects to create the report of "Losses by 






Mission and by Aircraft Type During the 






Past Date " 


R9.26 Calculates the results of query (R9.25) U11 


R9.27 Displays losses by mission and by aircraft (Willy evident 
| eal type during the past date 


R10.5 Changes time of displaying messages on the | None 
screen 1-5 sec 


R10.6 Changes color of the screen None 
R10.7 Locked keypad to arrows Yes/No None 
R10.8 Convert box characters Yes/No None 


R10.9 Showing bombing on map Yes/No None 








optional 


optional 





optional 


optional 
optional 


optional 














GS Function Sas 
Highlights steel for LCD/Mono screen 


None optional 
Yes/No 


Table 1. System Functions 







H. SYSTEM ATTRIBUTES 


is Attribute ’ Details and Boundary Constraints _ 
Response time When entering new values, the system 
must give the opportunity to enter the next 


item in | sec. 


Response time When user asks to see a report or 
information list, system must displays the 
report on the screen in 5 sec 


Response time System must execute an ATO and moves to 
i the next state in 5 sec 
Response time System must start printing the reports in 15 


Interface metaphor Forms-metaphor windows and dialog boxes 


Operating system platform (initially) Microsoft Windows 95 and NT 





Table 2. System Attributes 
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I. USE CASES 


1. High Level Use Cases 


Wik 
Oe 
OER 
U4: 
| Oho 
U6: 
Oe 
U8: 
U9: 


Start Employment Module 

Student Info 

Load an ATO 

Manage an ATO 

Describes the 20 Targets with Highest Priority 
Plan an ATO 

Fly an ATO 

Initial Information 

Estimated Results 


U10: Actual Results 


U11: Map 
U12: Send Exercise 


USE CASE (U1): START EMPLOYMENT MODULE 


Actors: 
Purpose: 


Overview: 


Type: 


Cross References: 


Student 

Start the Employment Module 

Student selects to use the CAMPEX Employment Module, the 
program displays the Introduction Reports and “Ground Forces 
Report”. The student can select to see only the “Ground Forces 
Report” and as alternative to continue with the program. 

Primary and essential 

eo mio ee S25, 3.4, R35, R3.6, R3.7, R38, R99, RS. 10, 
Roce Sere 1 oS. 14, R3.15,.R3.16, R3-17; R3,19, R3.20, 


R3.21, R3:226R 7 On 
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USE CASE (U2): STUDENT INFO 


Actors: Student 
Purpose: Student identifies himself 
Overview: Student enters his Personal Information in the CAMPEX. If he has 


already entered his personal information, he just selects his own 
name. 

Type: Primary and essential 

Cross References: Rall: Ro 2awles RaletR 1.5, Rio: Ri? RIO 11. RIO fz, 


R10.13, R10.14, R10.15 


USE CASE (U3): LOAD AN ATO 


Actors: Student 
Purpose: Load an ATO 
Overview: Student selects an ATO to load. When completed, student will 


enter the "Main Menu" and the selected ATO 1s loaded. 
Type: Primary and essential 
Cross References: R42 RIG | SRIOATORTO1Z RIO R10 14 
Use Cases: Student must have completed the 
e "Start Employment Module" Use Case (U1) 


e "Student Info" Use Case (U2) 


USE CASE (U4): MANAGE AN ATO 


Actors: Student 


Purpose: To allow student to manage to the ATO’s 
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Overview: 


Type: 


Cross References: 


Student wants to manage to an ATO. When completed, student will 
return in the "ATO File Management" menu a he can continue 
by loading an ATO. 
Primary and essential 
R4.1, R4.3, R4.4, R4.5, R4.6, R10.1, R10.11, R10.12, R10.13, 
R10.14 
Use Cases: Student must have completed the 

e "Start Employment Module " Use Case (U1) 


e "Student Info" Use Case (U2) 


USE CASE (U5): DESCRIBE THE 20 TARGETS WITH HIGHEST 


Actors: 
Purpose: 


Overview: 


Type: 


Cross References: 


PRIORITY 


Student 
Fill the list with 20 targets with highest priority 
Student has decided which targets of his plan have the highest 
priority. Student edits the list of 20 targets with highest priority. 
After the completion of this use case, the student’s "20 Highest 
Priority Target List" can be displayed by the application. 
Primary and essential 
Rake aR oak 4 RIO? RIOT RIO 12. R10 13, R10.14 
Use Cases: Student must have completed: 

e "Start Employment Module" Use Case (U1) 


e "Student Info" Use Case (U2) 


4.4 


e "Load an ATO" Use Case (U3) 


USE CASE (U6): PLAN AN ATO 


Actors: 
Purpose: 


Overview: 


Type: 


Cross References: 


Student 
Enters student’s plans 
Student enters new missions or edits old missions. With 
completion of this use case the student’s plans have been entered. 
Primary and essential 
Rose RO On ho ah oe h ome 10 el: 2, R1IO.11, R IOs 
R10.13, R10.14 
Use Cases: Student must have completed: 

e "Start Employment Module" Use Case (U1) 

e "Student Info" Use Case (U2) 


e "Load an ATO" Use Case (U3) 


USE CASE (U7): FLY AN ATO 


Actors: 
Purpose: 


Overview: 


Type: 


Cross References: 


Student 

To execute the planned missions 

Student is running fly missions. System calculates the result of the 
planned missions. Saves the results in a new ATO. Loads the new 
ATO. 

Primary and essential 

R6.1, R6.2, R6.3, R6.4, R6.5, R10.2, R10.11, R10.12, R10.13, 


R10.14 
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Actors: 


Purpose: 


Overview: 


Type: 


Use Cases: Student must have completed: 
e "Start Employment Module" Use case (U1) 
e "Student Info” Use Case (U2) 
e "Load an ATO" Use Case (U3) 


e "Plan an ATO" Use Case (optional) (U6) 


USE CASE (U8): INITIAL INFORMATION 
Student 
Inform student for the initial data of an ATO 
Student asks for initial information. With completion of this use 
case, the student has seen or printed the information that he has 
asked for. 


Primary and essential 


Cross References: Reel R72. R7.3, R74, R7.5, R7.6, R7.7, R7.8, R7.9, R7.10, 


Actors: 


Purpose: 


R10.2, R10.11, R10.12, R10.13, R10.14 

Use Cases: Student must have completed: 
e "Start Employment Module" Use Case (U1) 
e "Student Info" Use Case (U2) 


e "Load an ATO" Use Case (U3) 


USE CASE (U9): ESTIMATED RESULTS 
Student 
Display the estimated results of the student plan before executing 
the plan 
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Overview: 


Tvpe: 


Cross References: 


Student asks for the estimated results. With completion of this use 
case estimated results are displayed on the screen. 
Primary and essential 
R8.1, R8.2, R8.3, R8.4, R8.5, R8.6, R8.7, R8.8, R8.9, R8.10, 
Rogie olizenSl3.R)10.2, R10 11, RIOW2 Rig 13, R10.14 
Use Cases: Student must have completed: 

e ‘Start Employment Module" Use Case (U1) 

e "Student Info" Use Case (U2) 

e "Load an ATO" Use Case (U3) 


e "Plan an ATO" Use Case (optional) (U6) 


USE CASE (U10): ACTUAL RESULTS 


Actors: 
Purpose: 


Overview: 


Type: 


Cross References: 


Student 

Inform student of the Results Reports of an ATO 

Student asks for information. With completion of this use case, the 
student has seen or printed the information that he has asked for. 
Primary and essential 

ROI ORD) 2 tik oe Ro neo Gina ek Slee 
R912, R9.13, R914, R915, R916, ROT ROS, RO 19RD. 20; 
RO 2) RO 22 RD 230Ro 24 ko Zoek 2o.ko.2/7, RI) 2 Ree 
R10.12, R10.13, R10.14 

Use Cases: Student must have completed: 


e "Start Employment Module" Use Case (U1) 
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e "Student Info" Use Case (U2) 
e "Load an ATO" Use Case (U3) 


e "Fly an ATO" Use Case (U7) 


USE CASE (U11): MAP 


Actors: 
Purpose: 


Overview: 


Type: 


Cross References: 


Student 
See the map of the exercise area 
Student selects to see the map via the Main Menu. When 
completed, the map 1s displayed on the screen. 
Primary and essential | 
RIOZeRIGs 
Use Cases: Student must have completed: 
e "Start Employment Module" Use Case (U1) 


e "Load an ATO" Use Case (U3) 


USE CASE (U12): SEND EXERCISE 


Actors: 
Purpose: 


Overview: 


Type: 


Student 

To send the results of an exercise to "Air University" 

Student must be connected to the “internet” first. Then, selects the 
Option "Send Exercise Results to the Air University" and selects 
an exercise from the displayed. With the completion of this use 
case, the selected exercise results are sent to the Air University 
server. 


Primary and essential 
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Cross References: RZ. aR aR 3 R24. R1015 
Use Cases: User must have completed the 
e "Student Info" Use Case (U2) 


e User must have connected to the Internet 


2 CAMPEX Employment Module Use Case Diagram 


User starts the CAMPEX by identifying himself, and by this way the results of the 
exercise execution will have an owner. 

Then the user selects to start the CAMPEX Employment module. 

The last use case that is described by the CAMPEX Employment Module use case 
diagram is "Send Exercise." With this use case, the user can send the results of an 
exercise to the Air War College server. The sent results have the user ID and the Air War 


College Instructors can identify the owner. 
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Figure 8. Use Cases Diagram 


J. RANKING USE CASES 


Medium 


Fly ATO (U7) 


Plan an ATO (U6) 


Describes the 20 targets with highest 


priority (U5) 





SO 


Results 


/ Send 
Results 


Dependency from 
Actor Actions 





ror rrr) 


Dependency from 
other Use Case 


Important because it 
initiates the Employment 
module. 

Most important and highest 
risk process. 

Important because it allows 


the student enter his plan. 


Important because it allows 


the student to enter his plan 


Medium 


Low 


Student Info (U2) Affects the identification of 









the exercise results. 







Start CAMPEX Employment Module 
(U1) 


Affects the initial phase of 
the CAMPEX 








Send Exercise (U12) Affects the process of 


ranking the exercises. | 


Manage an ATO (U4) Affects the initial phase of 


the module. 


Initial Information (U8) Informs student about the 


current data. 





Estimated Results (U9) Informs student about the 















changes that will happen to 





the data. 






Informs student about the 






Actual Results (U10) 


new State data. 






Map (U12) 






Minimum effect on the 





processes 


Table 3. Ranking Use Cases 
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Figure 9. Conceptual Model. 
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IV. SOFTWARE DESIGN SPECIFICATION (SDS) 


ae INTRODUCTION 


ie Purpose 


This chapter specifies the design for the Campaign Planning Exercises 
(CAMPEX) Employment Module and presents the interaction (collaboration) and object 


diagrams that describe the overall CAMPEX Employment Module software. 


jee Scope 


This SDS provides extensive information concerning the designed and proposed 
functionality of the CAMPEX Employment Module. This chapter describes the 
subsystems that comprise the CAMPEX Employment Module. The sequence diagrams 
describe the individual CAMPEX object interactions via messages/methods. The object 
diagrams illustrate the specifications for software classes and the interfaces for the 


CAMPEX Employment Module. 


3. Definitions, Acronyms, and Abbreviations 


All definitions, acronyms, and abbreviations are included in Appendix C: 
“Abbreviations, Acronyms, and Definitions”. Abbreviations, acronyms, and definitions 


from the previous chapter have been carried forward for consistency. 
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B. THE SYSTEM ARCHITECTURE 


1 The Detailed Architecture Diagram 


Presentation Subsysem GUI 


ee oo) as ne =| ress 
Start ATO || hfanage ATO Inthal Estimated Actual 
ATO Pianmng | |Infcrmation|| Results Results 
Database Communication Seavices 
Intaf ace 
Storage Concepis 
== = fae aa aS a | 
Student ATO ; 
DATA BASE ATODay Massicn Repat Group 
Data Base Subsysem DATABASE Records Records Records Records Records Records 


es = al = | fe) 
Atreraft Base Target TetCategory || TetSubcategery|| Sector 
Records || Records Records Records Records Records 
i ee) 
Bomb | | Parameters 
Records Records 


Figure 10. Detailed Architecture Diagram. 





Application Subsystem 







The CAMPEX Employment Module has three subsystems. The Presentation 
Subsystem/Layer contains the Graphical User Interfaces (GUIs). The Application 
Subsystem/Layer contains the CAMPEX Employment Module high level object-oriented 


services, the services for communication with external devices and interface to the local 
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and remote database (Server of the Air War College). The Storage Subsystem contains 


the actual database. 


a. Presentation Subsystem 

e Object Class: Graphical User Interface. 

e Interface to Other Subsystems: Application Subsystem. 

e Human Interface: The GUI provides the only interface to the user of 
the CAMPEX employment Module. Chapter V User Manual provides 
a pictorial representation of the CAMPEX Employment Module 
human interfaces. 

e Overall Control Structure: The GUI is consisting of a number of 
Microsoft ACCESS 2000 Forms and Sub-forms. 

e Resource Allocation: The GUI first allocates resources that support the 
system screen and then allocates part of the system processing power 
and data storage space. 

e Data Stores and Management: The GUI subsystem does not store or 
manage data; it has no direct access to data, but it does offer a 
communication channel between the user and the Application 
Subsystem. 

e Global Resources and Management: The management of the global 
resources associated with the three CAMPEX Employment Module 


Subsystems is conducted through a time-sharing approach. Resources 


> 


are not shared equally among all the subsystems. The GUI uses most 

of the resources that support the screen operation, for example. 

Boundary Conditions: None. 

Constraints: The GUI of CAMPEX Employment Module cannot be 

made autonomous from the other subsystems of the CAMPEX 

Employment Module. The entire CAMPEX Employment Module 

prototyping will be provided in a Microsoft ACCESS 2000 runtime 

software package that includes all required bindings. 

Trade-Off Priorities: None. 

Design Decision /Rationale: 

e The GUI provides the only external interface to CAMPEX 
Employment Module. 

e ACCESS 2000 will be used in the GUI Subsystem. 


e All Forms and Sub-Forms are considered essential. 


Application Subsystem 
Object Class: See Figure 11. 
Interface to Other Subsystems: Presentation Subsystem. 
Human Interface: None 
Overall Control Structure: The CAMPEX Employment Module 
prototype uses sequential method to control] its tasks, with one active 


object to monitor and control] all tasks. The CAMPEX Employment 
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Module is procedurally driven; it uses fixed procedural loops to 
control the system. 

Resource Allocation: Allocation of resources is focused towards the 
timed processes required to monitor the GUI. A process that also sends 
objects to the Air War College allocates communication resources. 
Data Stores Management: The Data Base Subsystem is responsible for 
the management and storage of the data. The Application Subsystem 
has direct access to the data storage resources. 

Global Resources and Management: The objects within the 
Application Subsystem share the resources equally. 

Boundary Conditions: Startup, shutdown, termination, and failure 
should be performed/investigated by the system user. Details are 
provided in the user’s manual in Chapter V. 

Constraints: Employment Module prototype can be used as fully 
autonomous system when packaged as a Microsoft ACCESS 2000 
run-time including all the required bindings. Otherwise it can only 
work through Microsoft ACCESS 2000. Furthermore, the user must 
establish an Internet connection first to communicate and send 
information to the Air War College Server. 

Trade-Off Priorities: None 

Design Decision/Rationale: 

e Efforts were taken to minimize the use cases but the number was 


constrained by the required functionality. 


of 


e The CAMPEX Employment Module fully supports all physically 
challenged persons. 

e Visual Basic and SQL will be used through Microsoft ACCESS 
2000 in the Application Subsystem. 

e All functions are considered essential. 

e For the communication with the Air War College Server a DSN 


address will be used. 


Storage Subsystem 
Object Class: Data Base 
Interface to Other Subsystems: Application Subsystem. 
Human Interface: None 
Overall Control Structure: The Data Base consists of a number of 
tables and various types of queries. 
Resource Allocation: The Data Base uses about 10 MB of hardware 
storage in the system at any time and allocates additional space for 
queries. 
Data Stores and Management: Microsoft ACCESS 2000 handles the 
storage for the Data Base. 
Global Resources and Management: As described above in Resource 
Allocation. 


Boundary Conditions: None. 
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Constraints: Data Base is constrained by the ACCESS 2000 general 
constraints. | 

Trade-Off Priorities: None. 

Design Decision/Rationale: 

e ACCESS 2000 will be used in the Data Base Subsystem. 

e DSN address describes the address of the Air War College Server. 
e All functions are considered essential. 


e The user has no direct access to the Data Base. 
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OF 


OBJECT/CLASS DIAGRAMS 


1. Object Diagram 
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Figure 11. CAMPEX Employment Module Object. 
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2 Classes-Objects Attributes and Operations 


a. Class Employ 


1/ Attributes 


Attribute Description 


Hi_7Damage Integer Parameter for calculation 
KillRatioGood Integer Parameter for calculation 
Integer Parameter for calculation 


RedAbort Integer Parameter for calculation 


RedFEBALoss Integer Parameter for calculation 


ShowEnemyBmbrsOverBlueBases 
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Table 4. Class Employ—Attributes 






2/ Operations 
| initStudentServicesGUI None Student (all existed) 


initSelectATOGUI ATODay (all existed) 
InitCopyATOGUI ATODay (all existed) 


init20T gtHighestPriority None Targets (all existed, 









displays the first 20 with 






higher priority) 


InitPlanEditMsns m: Mission (all existed) 


AddStudent SSN, rank, firstName, | None 
lastName, country, 
address, e-Mail, 
section 


loadATODay SSN, description, day 


AddATO SSN: Text, None 






description: Text 


selectATOToCopy SON dex. None 





description!: Text, 


description2: Text 
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Sirs tape [opt 


eraseATO | SSN: Text, 
description: Text 


modifyT et SSN: Text 
description: Text 
day: Integer 
tgtNbr: Integer 
priority: Integer 


enterMsn st: Student, 
a: ATO 
ad: ATODay 
taskType: Integer 
ac{tType: Integer 
base: Integer 
sector: Integer 
tgtCategNbr: Integer 
tgtSubNbr: Integer 
bmbTypeNbr: Integer 
nbrOfSorties: Integer 
package: Integer 


deleteMsn SSN: Text 












description: Text 





day: Integer 






msnNbr: Integer 


SSN: Text 










deletePackage 





description: Text 






day: Integer 






package: Integer 
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Operation Output 


sortiesAvailable None r: Report 


yesterdayLossesByTask None r: Report 


selectATOToSend SSN: Text, None 





None r: Report 
r: Report 
r: Report 
r: Report 


r: Report 


description 1: Text, 


description2: Text 
updateStudent st: Student st: Student 
selection: Boolean 
updateReport r: Report None 
g: Ground Unit:=Null 
ad: ATODay 








updateATODay None 


selection: Boolean 





deleteATOday ad3: ATODay None 


addGroup ad: ATODay | None 
g: Group 

addSector ad: ATODay None 
s: Sector 
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addT gt ad: ATODay 


! 





None 
addMsn ad: ATODay None 
clacMsnLosses m: Mission 





updateMsn m: Mission None 
ad: ATODay 
I: Integer Array 


updateReport r: Report None 


m: Mission 


er: Integer Array 


calcLogReq Ir: Integer Array 
calculateAnalysis ana: Integer Array 


calculateSortiesAvailable m: Mission as: Integer 





g: Group 


calculateCumSumP 1 csl: Integer Array 
calculateCumSumP2 cs2: Integer Array 
calculateCumSumP3 cs3: Integer Array 


calculateEnemyOverBlueBases eobb: Integer 


calclateOverIndicators m: Mission o1: Integer Array 


los: Integer 













m: Mission 






calculateLosses m: Mission 


m: Mission 






addStudent st: Student 
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updateReport None 





Table 5. Class Employ—Operations 
b. Class Student 


1/ Attributes 


Selection True for the current Student 


Table 6. Class Student—Attributes 





Dh Operations 


getStudentAll St: Student 


Table 7. Class Student-—Operations 


Operation 
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Cc. Class ATO 


1/ Attributes 


Selection True for the current ATO 


Table 8. Class ATO-Attributes 














ye Operations 


getATO a: ATO (all existed) 


addATO st: Student None 
description: Text 

getATO st: Student a: ATO 
description: Text 


con 
_ 
Table 9. Class ATO—Operations 






















selection: Boolean 








st: Student 





description: Text 


d. Class ATODay 


1/ Attributes 


Attribute ~~ - Description 
Selection Boolean True for the current ATODay 


Table 10. Class ATODay-Attributes 
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Duy) Operations 


getATODay ad: ATODAY 
getATODaySel selection: Boolean ad: ATODAY 


eetATODayDay a: ATO ad: ATODAY 
addATODay a: ATO 
deleteATOdAY a: ATO 
getATODaySelandATO a: ATO ad: ATODAY 
selection: Boolean iter ae, 


Table 11. Class ATODay—Operations 











é. Class Mission 


l/ Attributes 


Attribute Description : 


isn 


NbrOfSorties Integer 


Priority Integer 
priority list 


SortieRate Parameter for calculation 
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Mission 


The number of sorties assigned in 









the Mission 


The priority for execution, 





describe by the Task Type that 
assigned to the Mission and by 


the user selection in 20 highest 













blueBombLoadQuantity Parameter for calculation 


Table 12. Class Mission—Attributes 





2/ Operations 
updateMsn taskType: Integer None 


acftType: Integer 


base: Integer 


sector: Integer 


tgtNbr: Integer 
tgtCaNbr: Integer 
tgtSubNbr: Integer 
bmbTypeNbr: Integer 


nbrOfSorties: Integer 





package: Integer 


deleteMsnAll ad: ATODay 
getMsnAll ad: ATODay m: Mission (all existed) 


getMsn ad: ATODay m: Mission 
msnNbr: Integer 


addMsn taskType:Integer 
acftlype: Integer 
base: Integer 
sector: Integer 
tgtNbr: Integer 
tgtCaNbr: Integer 
tgtSubNbr: Integer 


bmbTypeNbr: Integer 





nbrOfSorties: Integer 
package Integer 
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deleteMsn ad: ATODay None 
msnNbr: Inte ger 


deleteMsnPkg ad: ATODay None 
package: Integer 


deleteMsnBad ad: ATODay 


updateSector ad: ATODay None 
m.sector: Inte ger 
l: Integer 

updateGroup ad: ATODay None 
m.group: Integer 
l:Integer 

updateTarget ad: ATODay None 

| m.tgt:Integer 

l: Integer 


Table 13. Class Mission—Operations 

















f. Class Target 


1/ Attributes 


Attribute Description 
TgtNbr The number of Target 
Name Text The description of Target 
Nationality Boolean True for the Chinese Targets, 
meaning that they cannot be 


assigned to a Mission 


% Operational Integer The percentage operational of the 


Target 










Table 14. Class Target-Attributes 






2/ Operations 


getT gtAll ad: ATODay t: Target (all existed) 


updateT gt ad: ATODay None 
tgtNbr: Integer 
priority: Integer 


Table 15. Class Target—Operations 









g. Class Category (Target) 


Attributes 


CategoryNbr Integer Unique number for every 


category 


RiskInZone Integer Parameter for calculation 





Table 16. Class Category—Attributes 


h. Class Target Subcategory 


Attributes 


i. 


SubcategoryNbr Integer Unique number for every 


subcategory 


Table 17. Class Subcategory—Attributes 





L. Class Group 


Uy Attributes 


Unique number for every group 


AcftAvailable Integer Number of aircraft available in 


group 


Losses Losses of group from the start of 
the game 


Table 18. Class Group—Attributes 





oy | Operations 


enero tape [att 


Table 19. Class Group-Operations 






J. Class Aircraft 


l/ Attributes 


AcftT ypeNbr Unique number for every aircraft 

















Parameter for calculation 


Table 20. Class Aircraft—Attributes 














2 Operations 


getAcftT ype acft: Aircraft 


Table 21. Class Aircraft—Operations 













k. Class Sector 


Ly Attributes 


SectorNbr Unique number for every sector 


BlueFrontLine Integer Parameter for calculation 


RedFrontLine Integer Parameter for calculation 
BlueReinfRate Parameter for calculation 
RedReinfRate Integer Parameter for calculation 


CurFEBApsn Parameter for calculation 
GroundResults Integer Parameter for calculation 
BluePosition Parameter for calculation 


fis. 





RedPosition Parameter for calculation 


Table 22. Class Sector—Attributes 


2/ Operations 


a 


Table 23. Class Sector—Operations 










m. Class Task Type 


1/ Attributes 


Attribute a 2 Type | Description 


TaskT ypeNbr Unique number for every task 


TaskT ypeName Description of task type 


a Se Integer Parameter a, calculations 









(abbreviation of ATO type 


mission) 


‘cule tamale Integer Parameter a a. calculations 


FEBAlossIf{DSUP Parameter for calculations 
FEB AlossIfDS AandDS UP Parameter for calculations 


DofFightProbBasic Integer Parameter for calculations 


DogFightProbIfDSE Parameter for calculations 


DogFightProbIfC3 Parameter for calculations 


DogfightProbIfDSEandC3 Parameter for calculations 
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4 a 


Description 





Type 





7 Attribute 
Integer Parameter for calculations 


Integer Parameter for calculations 
TermLossIfDSUP Integer 


Table 24. Class Task Type—Attributes. 


- 
e 
























2/ Operations 


getTaskT ype tsk:TaskT ype 


Table 25. Class Task Type—Operations 






n. Class Bomb Type 


Attributes 










Attribute Type Description 


BombTypeNbr Unique number for every task 
bombT ypeName Text Description of bomb type 


Table 26. Bomb Type—Attributes 








is 


0. Class Map 


ly Attributes 








MapNbr Integer Unique number for every map 


MapDescription Description of map 


Table 27. Class Map—Attributes 












2 Operations 


Table 28. Class Map—Operations 












p. Class Report 


Vi Attributes 


ReportTitle Text Unique number for every report 


Table 29. Class Report—Attributes 





2/ Operations 


_ - 
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ite Te 


Glee xt 
Table 30. Class Report—Operations 









We) 


THiS eAGEAINTENTIGNALLY LEFT BEANK 
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V. PROTOTYPE 


A. PURPOSE 


The purpose of this chapter is to describe the way that the prototype is 


implemented. It also provides a "User Manual" of the prototype for easy using. 


B. PROTOTYPE IMPLEMENTATION 


1. General 


The prototype was implemented with Microsoft Access 2000 for the following 
two reasons. 

First, most of the use cases can be implemented as interactions between the GUI 
subsystem and the Database subsystem without involving the Application subsystem. 

Second the number of functions of the application 1s big and the available time is 
not enough to implement the Design Specification with a classical object-oriented 
language. 

The use of ACCESS 2000 cannot fully prove the object-oriented Design 
Specification of Chapter IV. Yet it proves the correct design of Database, can be used for 
the verification of the Requirements Specification of Chapter II, and partially prove the 


correctness of the Objects’ attributes and interactions. 
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pa Database Design 
The Prototype consists of Tables, Queries, Forms, Macros and Reports. The 


Database Entity-Relationship Diagram constructed by the ER-Win 3.5 tool of "Logic 


Works" is displayed in Figure 12. 
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Figure 12. Entity-Relation Diagram (Logic Works ER-Win 2.0 Database Design 
Tool.) 


Entities — Relations Attributes 


|_| _RelationName | ss AttributeName | Key | Type 
1. | STUDENT 


StudentSSN Primary | Text 
Key 
(PK) 
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eel Relation Name AttributeName | Key | Type | 


StudentFirstName Text 
StudentLastName pf Text 


RankAbbr Foreign | Text 
nae 

StudentClassNbr |_| Integer 

StudentSelection Yes/No 


ATODescription 


ATOExecutionTime Integer 


ATOINFORMATION 


ATODAY 





ATODescription Primary | Text 


i | oe 
RANK 


Raibeion TE 


BlueAcftT ypeName lence Text 
BlueAcftTypeInComPercent a | Integer 


Bheketpeboecen ae 

Bhekeypereeesarie 

BheketTipeicabnremear [Tae 

BescaiTeGalCapsy | [Ta 
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BLUEACFTTYPE 


| | Relation Name Attribute Name | Key | Type _ 
Set veo 


BlueBaseAbrreviation Text 


BlueBaseFullName | <a Text 


BlueBasePercentOCA ae Double 
BlueBaseNbr PK-FK 


BlueAcftTypeNbr PK-FK 
BlueAcftAmmount — | Integer — 


ATOExecutionTime PK-FK_ | Integer 


BhesatAmmm | 
[BDORTASRRRPE 


BlueMissionT ypeNbr Integer 


6. BLUEBASE 


BLUEGROUP 


8 BLUEGROUPEXE 









West 









BlueMissionName 
FEBATonDSA nL 


FEBAlIDSUP pea 
















FEBAlossIfDS AandDS UP Double 
DofFightProbBasic | | Double | 
DogFightProbIfDSE Double 


DogFightProblfC3 Double 
DogfightProbIfDSEandC3 Double 


eae 








TermLossBasic 


Relation Name : Attribute Name | Key | Type _ 


Tembosimser | oat 


TermLossIfC3andDSAandDSUP ) | Double | 


Lr 


oo 
BLUEPROPERACFTPERMISSION 
Palate RI bask 


BLUEBOMBSPERACFTMSNTYPE 
BlueAcftTypeNbr PK-FK_ | Integer 
BlueMissionTypeNbr PK-FK_ | Integer 


BlueBombNbrPerAcftMsnBomb || Integer | 


13. | BLUESORTIES RATEBYMSNACFT 


BlueAcftTypeNbr PK-FK 
|BlueMissionTypeNbr PK-FK 
BlueMsnAcftTypeRate eka ——— 


= BLUEACFTTYPEBOMBLOADANDDISTANCE 


BlueSpCharacteristicNbr PK Integer 
BlueBombTypesNbr PK -FK | Integer 


(10. BLUEBOMBTYPE 


BlueBombLoadAmmount Integer 


BlueRangeWithLoad |_| Integer 


83 


ll Relation Name Attribute Name | Key | Type | 


15S. | BLUECASBOMBLOAD 


BlueAcitT ypeNbr PK-FK 
BlueBombTypesNbr PK -FK 
BlueBombLoadQuantity 


BLUEWEASELACFTYPEBOMB 
BlueAcftTypeNbr PK-FK_ | Integer 


BlueBombT ypesNbr PK -FK 


17. | BLUEMISSIONSPECCHARACTTYPES 


BlueSpCharacteristicNbr 
BlueSpCharacteristicDescriptionr = © Integer 


18. | BLUEMISSIONCHARACTERISTICS 


BlueSpCharacteristicNbr PK-FK 


BlueAcftT ypeNbr PK-FK_ | Integer 


BlueMissionT ypeNbr PK-FK 


SECTOR 


SectorName Text 
SeseBiesAcenNed [Dt 
SectorBlueReccePercentNeed Integer 
Seceeeontine inne 
Ea 


SectorRedFrontLine Integer 


SectorRedReinforce | | Integer | 


ATOExecutionTime PK-FK 

ATODescription PK-FK 

StudentSSN PK-FK 
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SECTOREXE 


pea Relation Name Attribute Name | | Key | Type | 


CurrentFEBA Position —~ 4 Integer | 


ees ae 
BluePosition Integer 
Rearesion 


RedTargetDescription [Text 


ZoneNbr FK Integer 
RedTargetLatidute | Double 


RedTargetLongidute | | Double | 
RedTargetChinese || Yes/No 


ZoneNbr Integer 


I 
REDMISSIONTYPE 
es a 
i 
REDTARGETCATEGORY a 
Linsaacn ns Mel 


REDTARGETSUBCATEGORY 
TargetSubCategNumber 
TargetCategoryNbr PK- FK 






21. | REDTARGET 











22. | REDTARGETZONE 


TargetSubCategDescr ae Text 


TargetSubCategRebRate | | Double 
TargetSubCategRebTimes | | Integer 
REDTARGETCATEGORYSUBCATEGORY 
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[4 Relation Name __ ____Attribute Name | Key | Type | 


TargetSubCategNumber PK- FK | Integer 


TargetCategoryNbr PK- FK 


Aten lltacaliad: PK -FK 


REDTARGETOPERATIONAL 


Sa a 
REDTARGETOPERATIONALEXE 


StudentSSN PK-FK | Text 
TargetCategoryNbr PK- FK | Integer 
RedTargetNbr PK -FK 


ReccePercentOperational | | Integer 
MaxPercentOperational | | Integer 


RedBaseDescription ) | Text 


RedAcftDescription 2 | Text 


RedAcftTypes PK -FK | Integer 
RedBaseNbr PK -FK | Integer 


REDBASE 


30. | REDACFTTYPE 


REDGROUP 


RedMissionT ypeNbr Integer 


RedAcftNumber / [Integer - 
86 


RedMissionTypeSortyRate || Integer | 


ATOExecutionTime PK-FK 
ATODescription PK-FK 


StudentSSN PK-FK | Text 
RedAcftTypes PRE Ko iminteser 


RedBaseNbr PK -FK 
RedAcftNumber _ 2 Integer 
eats ae 


REDSHELTERSTATUS 
bei A 
REDBASEACFTTYPESHELTERSTATUS 


EMPTY 20HIGHESTPRIORITYLIST 


REDGROUPEXE 


Priority Ris Integer 


REDTARGET20HIGHESTPRIOTIYLISTEXE 


ATOExecutionTime PK-FK | Integer 
ATODescription PK-FK | ies 


StudentSSN PK-FK 


REDBASECATEGORYDIFIICULTY 
RedBaseNbr PK -FK 


TargetCategoryNbr PK- FK 
TargetSubCate gNumber PK- FK 
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| | Relation Name Attribute Name | Key | Type | 


RECCETGTPSN 
ATOExecutionTime PK-FK 
ATODescription PK-FK 


StudentSSN PK-FK | Text 
RedTargetNbr PK-FK_ | Integer 


FlightNbr PK-FK | Integer 


ATOExecutionTime PK-FK 
ATODescription PK-FK 


StudentSSN PK-FK | Text 
FlightNbr Integer 


SectorNbr 


TargetSubCategNumber Integer 


FLIGHTDATA 


TargetCategoryNbr Integer 
RedTargetNbr Integer 


BLUESORTIE0_7ACFTBOMBTGTATSUB 


41. | BLUEPRIMARYUNIT 


TP RCORPRIARVORT 
LS 
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ae Relation Name Attribute Name | Key | Type | 


PrimeUnitName | Text 


ii cael taeda 
PrimeUTC PK-FK 


ArmyDivs 4 Integer 
Nbr2 Integer 


a 
pee 


ReportLabel Text 
OBE 
Object 


DEPLOYDATA 


43. | REPORT 


ReportText 


44. | PARAMETERS 


Hi_5Damage Integer 


Lo_5Damage Integer 
Hi_7Damage Integer 
Lo_7Damage 


NotFireAt 


Integer 
Integer 
DogFightBasicLoss 
KallRatioBad 
KallRatioEven 
KiliRatioGood 
MinWorstRatio 
MinBestRatio 
PercentRedDCA 
PercentRedOCA 


Integer 
Integer 
Integer 
Integer 
Integer 
Integer 


Integer 


Integer 
PercentRedFlying 
MaxPercentRedAcftLost 


Integer 


Integer 


00 
\O 


a Relation Name | Attribute Name imekeyar Type % 


a 
RedFEBALoss 
Le 


ShowEnemyBpmbersOverBlueBases Integer 


geese | 
senaiDegneeGre [nae 
AeiGaauneer [ia 
[SeabiTenoreFEBA | [ia 
Petar fie 
BottomLat Integer 
a 
La 


Table 31. Entities — Relations Attributes. 


The Database Entity-Relation Diagram of Figure 12 and the Relations’ description 
of the table above can also be used as Database design for the implementation of the final 
Application. The prototype’s database contains some extra relations that are used for the 
calculations only and should not be included in the final application database. This kind 
of relation has the prefix "TMP" for easy recognition from the main relations of the 


database. 
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The prototype was a combination of ACCESS 2000 Forms, Visual Basic code, 
queries, and macros to provide user friendly GUI. The GUI design and probably the 
implementation can be used for the final application. 

The queries are written by the special ACCESS 2000 SQL. In the case when a 
query is very complicated to be executed, nested queries that construct temporary tables 
are used. The use of nested queries reduces the prototype’s performance because of its 
extensive use of the storage devices, which are the slowest components of a computer. 
On the other hand, it offers the functionality that the prototype needs. 

Macros are used mainly for two reasons to create a sequence of events (queries) 
and to offer runtime information to the GUI. 

Reports are used only for printing necessities and they are the printable versions 


of GUIs (Forms.) 


C: USER MANUAL 


IL. Installing CAMPEX Employment Module Prototype 
e Recommended System: IBM PC-compatible 486 computer running 
Microsoft WINDOWS (NT 3.5 or 98) or higher, with minimum 16 MB 
RAM and minimum 256-color monitor. 
e Copy the file CAMPEX2000.mdb from its source to desktop (a shortcut is 
created.) The size of the prototype is expected to be 10 MB when it needs 
ACCESS 2000 to run (current version) and above 25 MB if it can run as 


an independent application. 


2) 


a Running the CAMPEX Employment Module Prototype 
e Double click on the application icon and the program starts to execute. 
e In every screen student has the choices "Return" and "Exit." With 
"Return," the system returns to previous screen, and with “Exit,” the 


system quits the application. 


fe 





Figure 13. Return and Exit 


5: CAMPEX Employment Module Initial Screen 


The Initial screen of CAMPEX Employment Module appears with one menu bar 
on the top of the screen named "Student", with three choices: 
e "New Student" must be selected if the student executes the program for 
first time. 
e "Select Student", must be selected if student has already input his personal 
information in the program. 


e "Exit" to quit the application. 
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Figure 14. Initial Screen 


4. ''New Student" 
e Anempty “Student” record is displayed. 


e Enter the necessary student information. 


e Fill all data fields. 


e Select return. 
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RETURN 
Figure 15. New Student 
=: "Select Student " 
e System returns a list of student names. 


e Select a name from the list. 


e Select "Continue." 
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MECC AECS ae ee vat ox EO 


Select your Name; | 
TRELERELE Antanios ba 
eS hei 111-11-1112 Loukas Hal 
saaiiad 11 1-11-1113 Konstantinos Samb 
111-411-1114 Bill Carrol 
111-111-1115 stamatis Ealtzis 
111-11-1116 Panos Barberis 
4111-11-2222 Minas Laoutaris 


CONTINUE RETURN 





Figure 16. Select Student 


6. "Start Employment Module" 
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We suggest you to view the Program Reports at least the first time you rum this program {some may 
contain critical information.) You may also view them later by using the “Options” menu off rein 
Menu . 


Click ta see the Program Reports _ +» Click to continue with program 


Bee 


Pic 


RETURN 





Figure 17. Choose to see Reports or Not 


e "Click to See the program Reports" must be selected if the student wants 


to see the "Introductory Reports." 


2) 


e "Click to Continue with Program" must be selected if the user wants to 


continue with the program without seeing the "Introductory Reports." 


ce "Click to See the Program Reports" 

A screen with the first Introductory Report will be displayed. Student can see the 
report by using the right screen scrollbar, by clicking inside the report and by using the 
keyboard up and down arrows. Notice that the student has seen the whole report only if 


he is able to see the note "Last Line,” written with red letters. 


"WEATHER REPORT 


ste tet setannceneadamhal Oita wees aren snow veuaaue ep Nawld dpeewacan wes da vedie ude cwanvevdtadae te ava wea nee 


eather Report 
Dateline 31 Mar 97 


High alttude cloud cover is expected over the area of operations for the next three weeks. 


Satellite recce sources will be of mimmum use dunng this time. 


“Continue 
4% i vijraf ot 9 





Figure 18. Introductory Report 


Select (») to continue with the next "Introductory Report." 
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8. "Click to Continue with Program" 


A screen with the "Ground Combat Units as of Day 1" will be displayed. This 
report is always empty, because the information it contains is a product of "CAMPEX 


Deployment Module" that has not yet been implemented. 
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Figure 19. Ground Combat Units 


Select "Continue." 


9. "ATO Selection" 
e "Select an ATO" must be selected if the student wants to execute an 


existing ATO. 


e "If the ATO is not on the list Click the Button to Enter" must be selected if 


the user wants to enter an ATO that is not existed in the list. 


| 


10. "Select an ATO" 


e Select an ATO description. 


e Select an ATO day. 
SQ ATO SELECTION cs 


a ra 


_ Select ATO t0 Execute: a [EE 


‘ifthe ATO ig notin the List ° 
click the button to enter: | 


- ater ety ATC tn oF Day 


CONTINUE RETURN © 
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Figure 20. ATO Selection 
If the student selects an ATO day, all the days following the selected day and their 


information will be deleted. 


11. "New ATO "' 


An empty ATO record is displayed, if the student selects "If the ATO is not on the 


list click the Button to Enter”. 
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Enter new ATO Name: [i 


RETURN 


Figure 21. Enter a New ATO 
e Enter the necessary information. 
e Select “Return”. 


Program returns to the previous screen and user must select an ATO to continue. 


12. ‘Main Menu Screen" 
On the top of the screen a new "Menu Bar" will be displayed with three 


choices: 
e "Options." 
e "ATO Planning." 


e "Intel and Results." 
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Figure 22. Main Menu 


13. "Options" 

e "Open Introductory Report" must be selected to see an Introductory 
Report. 

e "Area Map" must be selected to see the Area Map. 

e "Change ATO" must be selected to return to the state of selecting an ATO. 

e "Blue Basing Summary" must be selected to see the blue "Basing 
Summary” report. 

e "Sorties Available" must be selected to see the blue "Sorties Available" 
report. 


e "Analysis" must be selected to see the blue "Analysis" report. 
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Figure 23. Options Menu 


14. "Open Intro Report" 


System returns a list with all Introductory Reports’ Titles. 


e “Select a title from the list.” The selected Report will be displayed, 
pressing the “Return” button will return to the “Report Management 


Screen.” 
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REPORT MANAGEMENT 


Select a Report to see Or Update a Report 

a es = ce te 3 EXECUTE ORDER 
DIA INTEL UPDATE 
THAI! FORCES AVAILABLE 
WEATHER REPORT 
NAVY UPDATE 
[WEAPONS AVAILABILITY UPDATE 
PROGRAM NOTES 
BOMB DAMAGE ASSESSMENT AND TARG . 





Figure 24. Report Management 


15. "Area Map " 
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Figure 25. Area Map 
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16. "Change ATO" 


"ATO Selection" screen will be displayed. User must follow the same known 


sequence as in the section 4.b.11. 


17. "Blue Basing Summary ' 


oo ede BASING SUMMARY FOR ATO 
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PRINT RETURN 


Figure 26. Blue Basing Summary 


18. "Sorties Available "' 


Odyseas 1 
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_ Available Number 
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Figure 27. Sorties Available 
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19. ‘Analysis 


MNES : 


‘None e Scheduled 
None Scheduled 
ee | None Scheduled 


f=" None Scheduled 
_No Comment — 


OE | wae ere ae _ Target Zone: 


EXIT. RETURN === —s—s—“‘éSS~ CT arget Zone: 


"Major 
Antonios Hal 





Figure 28. Analysis 


20. "ATO Planning" 
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Figure 29. Menu "ATO Planning" 
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"20 Top Priority Targets" must be selected to describe the 20 targets with 
highest priority. 

"Plan Edit Missions" must be selected to plan missions for an ATO. 
"Estimated Results" must be selected to see the "Estimated Results" report 
of his planning. 

"Flights Without Sorties" must be selected to see the "Flights Without 
Sorties " report. 

"Daily Summaries" must be selected to see the "Daily Summaries " report. 
"Cancel Mission or Package" must be selected to delete a planned mission 
or package of missions. 

"Logistic Requirements" must be selected to see the "Logistic 
Requirements " report. 

"Fly ATO Missions" must be selected to execute the planned ATO. 
System changes state to the next ATO day. 

"Ground Forces Deployed" must be selected to see the "Ground Forces 


Deployed " report. 
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21. ''20 Top Priority Targets "’ 


LIST OF 20TARGETS WITH HIGHEST PRIORITY =. = Qdyseas1 


/ [ Red Target Priority |” PEI. Select Targets 


_-Mengzi Airbase 
Bai Thuong Airbase 
Pleiku Airbase 
Cam Ranh Airbase 
Kep Airbase 
Haiphong/Kien Airbase 
Phu Cat Airbase 
Tuy Hoa Airbase 





Figure 30. List of 20 Targets with Highest Priority 


e Select the priority number, and then select a Target from the list. The user 


cannot select the same target more than once in a Priority List. 


Lp 2 "Plan Edit Missions " 


e "Aircraft Type." 
e "Blue Base.” 


e "Red Base or Target Number." 
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e "Target Type." 

e "Zone of Target.” 
e "Task Type." 

e "Packages." 


e "List All." 


) Blue Base : 

Red Base or Target Number: 
Target Type : 

Zone of Target : 

Task Type : 


Packages : 


List All: 


Major 
Antonios Hal 





RETURN —s EXIT 


Figure 31. Flight Categories 
Only the Flights in the planned missions will be displayed. Selecting the “List 
All” option will results in the display shown in Figure 32. The user can see the planned 
missions up to that moment now by the selected choice. 
Select "To Enter a new Flight or to edit an existing click the button below" to 


modify flights. 
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- AllAssigned Flights 





Flight: bcsion A ype: ' AucraftType Blue Base Abrieviation Blue Base Name dl — TgtNbr Target Descriat | 



















1 OCA F-16 ie Ubon 9/Pleiku Airbase 
mc FAB y 





mh ~ rat 


oe 






BICAS OA10 








“To Entera new Flight or fo edit an existing 
iy - click the button bellow 


RETURN 


Figure 32. Assigned Flights By Category 


Ds Enter or Edit Flight "' 


e "To Enter a new Flight Enter the Flight Number and click on the Button 
below” must be selected to enter a new Mission. 

e "The numbers in the list already exist so you cannot enter them but you 
can edit them" must be selected to edit a mission. 

e Select an existed flight number or enter a new number will result in the 


display shown in Figure 34. 
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ENTER OREDITAFLIGHT 


To Enter a new Flight Enter the Flight The sumbers in the list already exist so you 
Number and click on the Button below ‘tannot enfer them but you can edit them _ 


RR a inet ae i ewe oe ane 


RETURN — 





Figure 33. Enter or Edit a Flight 


24. "Flight Data " 


e Enter the necessary flight information. 
e Fill all data fields. 


e Select “Return.” 


109 


FLIGHT DATA Odyseas 


Flight Number: 


Mission or Task: 

| Supported Sector: . rr =| 
Target: ad 

Targets For Recce: oes 


Target Category: 


P Click Boe Gane Mission 3 
| “For: ihe Selected ae J¥pe you cannot @s¢ igtt. & Se 
'For the Selected Mission Type you: cannot BS sign & Fat 
a Select four targets Only. for Recce 


— nical For the Selected Mission Tipe you cannot assign a Ta 


Tarot Clearance: és 
Target SAM: - * 


: aay | 


Blue Base: | we. J 


“Bomb | Quantity: - C fe 


For every Mission you have fo select an Aircraft Type 


Bil For every Mission you have to select. a Bie Base 


| For the Selected Mission Type you cannat select a Bar 


| Mission Package: : 


e Target Zone; Aa 





eye 


For the selected ¢Mission Fype. your must select ¢ a Targe 


RETURN oe os ga 


Figure 34. Input or Update Flight Data 


"Estimated Results Choices" 


"Aircraft Type." 

"Blue Base.” 

"Red Base or Target Number." 
“Target Type." 

"Zone of Target." 

“Task Type.” 

"Packages." 


"All Flights." 
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“Student Options “ATO Planning intel and Results ~ 


= SRY AtopProectytapes Pee e a) «leg -/ OQ. 





Plan Edit Mitsions : é F 
OA1D e. 
Flights Without Sortes biusBases 18 VI oa N UJ me 
‘Daily Summaries ReBase Or Target C130 1 OES 
_ Cancel Mission Or Package Target Catagory F1SE ~~ es 

Logishcs Requirements TargetZone wy , 
Rhy &TO Mecsions YaskType $18 5 
Ground Forces Deployed Mission Package FG By 


Al Flights > &-t74 


Figure 35. Estimated Results Choices 


Each of these choices leads to another menu of choices that 


describes a filter for the way that the user can see the "Estimated Results" report. 


26. "Estimated Results" 


ESTIMATED RESULTS FOR Odyseas 1 


Mission Task:.« Aircraft | Blue Base uy Target : Target [Target Target Target | Mission Sorties Assig: 
Number] “Type 4° Type poe: {Number] Type CLS: , pone [Package 
Mmaemiiss a ee ee 


EE ER eee ee Ee ee Ea Dee ee ee ee eee 
I tn _Zera Sorties Assig 


Ew YEAS oo erat | oe Se ak 2 
cas) [ons | NemPhong E Seciori Bee ES z ee roe: [eee J 22 


. Majer — 
 AntoniosHal 





RETURN, 


Figure 36. Estimated Results 
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27; "Flights without Sorties"' 


: FUGHES NINOUTSORTIES >. Odyseas 


Aircratt t Mission . Blue Base | Blue Base Name [Serties Sector: Target] Target Description... 
“Type Type [Abrreviation Coe ee Ee? ree ak 


‘Wumber} 


o Me: aaa joti Aiport os 

| | aC 
ML) EEL CS Le LC = LL nn eS y 
BG Cee Pica Mer ee ae ed Mengzi Airbase 


hen ee = 


BFA : NOVY ec SS x Le] one A BS %_ a[Mengtl Airbawe 


~~ i 7 _ —_ = = 
: : = : _ ae ate me ali ee NE tA tate ‘ 


/ Major : : a 
- antonios Hai ee . 


RETURN 





Figure 37. Flights without Sorties 


28. "Daily Summaries " 


PLANNED SORTIES c= % a sso TASK: TYPE FOR DAY. 





RETURN 


Figure 38. Daily Summary 
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ou: Cancel Mission or Package" 


CANCEL MISSIONS OR MISSIONS PACKAGES 


. ESE i 
(eT [eas[ Set [0p PAE] Nom Phong Po tO | 
BN 2 ESE OE as a 


“Select a Mission to Cancel ee "Select a Package t to Cancel the Missions 
= =a. 


1 
2 


RETURN 





Figure 39. Cancel Mission or Missions’ Package 


e "Select a Mission to Cancel.” 
e "Select a Package to Cancel the Missions." 
System returns a List of the planned missions or packages (depending on the 
user’s choice.) 
Select a Mission or Package Number. The system deletes the selected mission or 


the missions of the selected package. 


ps 


30. "Logistic Requirements " 


* LOGISTICSNEEDTOFLYDAY == s(Odyseas 


cc AC SE 











Antonios Hal a RETURN EXIT 


Figure 40. Logistics Requirements 


31. "Fly ATO Missions" 


System executes mission and changes state to the next day. 


a2: "Ground Forces Deployed" 


As shown Figure 18 
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33. "Intel and Results" 


ASDA 


A al mt Kin ROO em nh ee In tp ak Qc AAR A LIAR Kae Sn at ON AA a eS Pl sim mE NS Mee 
7 











nes POAAAIAY YAN 8 NANA ~ 


MORSE Gms Sowcehet "kB a- @ 





“Yasterday’s Losses Sy Task Type 
Yesterday's Losses By Acft Type 


Figure 41. Menu Intel Results 


They are active only if the user has executed a planning (Fly an ATO): 

e "Sorties Effect" must be selected to see the "Sorties Effect" report of his 
planning. 

e "Current Recce" must be selected to see the "Current Recce” report of his 
planning. 

e "Enemy Over Blue Bases" must be selected to see the "Enemy Over Blue 
Bases" report of his planning. 

e "Ground War Summary" must be selected to see the "Ground War 
Summary" report. 


e "View Measures of Merit" must be selected to see the "View Measures of 


Merit" report. 
Bs: 


e "Yesterday Losses by Task Type" must be selected to see the "Yesterday 
Losses by Task Type” report. 
e "Yesterday Losses by Acft Type" must be selected to see the "Yesterday 
Losses by Aircraft Type” report. 
Depending on the user’s choice, the selected report will be displayed. In addition, 


user can choose to print the report. 


Overall indicators thru 
) Odyseas2 | 
BAY [rss] er] | Total | Total Aircraft CR-Aircratt] Blue Lost | Red Lost. 





Weight of Effort By Army-Recce- Blue Attrition Percent Loss Ratio (Red/Blue) 
Other 


NASAL SANAE ABA SASAMANAAEAANASAAARESAN SN NANAAS AA SSANANAASSADATAASNIIA NSE 
. opYe Tae ss My Taek TS Ney Me 


Major e kA gg RETURN to Print 
Antonios Hal : te : : ae fd EXIT 





Figure 42. Sample Intel Report ‘“‘Measures of Merit'' 
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VI. CONCLUSIONS 


This thesis examined three distributed component architectures: Microsoft’s 
DCOM, Sun Microsystems’s JINI, and the OMG’s CORBA, and concluded that they 
have similar capabilities, but each has distinct strengths and weaknesses. CORBA seems 
to be the best solution for using legacy applications as components because of its ability 
to cross languages boundaries. In practice, however, most old applications cannot be used 
as components because they are not implemented using object-oriented technology. Thus, 
it is necessary to redesigned and re-implement the legacy applications using object- 
oriented technology before they can be used as distributed components. In this case, JINI 
in combination with the Java programming language comprises the most complete 
solution. JINI implementations are fully compatible to each other and Java supports 
extensive object-oriented design and implementation. 

The analysis and redesign of CAMPEX proved the concept that old applications 
are not useless. The old version of CAMPEX was the main source for the Requirements 
Analysis and Design Specification. The Requirements Analysis was a product of reverse 
engineering the old CAMPEX functionality and much of the detailed design are resulted 
from reverse engineering the CAMPEX source code. The process of reverse engineering 
was not cost free. It required more time and added difficulties and risks to the whole 
process. 

Using the Unified Modeling Language (UML) for the analysis and the design of a 
software product adds risk to the development process when the designer is not 
experienced in using the language. The primary advantage of the UML Methodology is 


that the processes overlap each other, thus the designer gain a more complete knowledge 
gy 


for the whole problem. On the other hand the overlap in the UML process consumes 
additional time. Moreover the design results are often ambiguous and different people 
can design the same product differently and different people can read UML products 
differently. For UML to give a clear view of a problem to everyone involved in the 
development process, it must be used in combination with customer and team reviews. 

CAMPEX uses a “Two Tier Architecture” through the choice of ACCESS 2000 
for the prototype implementation. A “Three Tier” object-oriented design could provide 
added benefits only under special circumstances. The designer must keep in his mind that 
one can validate fully the Requirements Specification, use the same GUI design for the 
final application and verify the correctness of objects, but one can only partially validate 
the design of object interactions. 

Keeping the prototype’s Database and GUI and implementing the computations 
with a classic object-oriented programming language will complete the CAMPEX 
Employment Module implementation. CAMPEX will be the basis for implementation of 
other Air War College planning modules. Parts of CAMPEX will be components of other 
modules, and CAMPEX itself will be a component in a distributed environment where 


students exercise air campaign plans. 
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APPENDIX A —- USE CASES 


USE CASE (U1): START EMPLOYMENT MODULE 


Actors: 
Purpose: 


Overview: 


Type: 


Cross References: 


Section: Main 


Typical Course Events 


Student 

Select to start the CAMPEX Employment Module 

Student Selects to use the CAMPEX Employment Module, the 
program displays the Introduction Reports and “Ground Forces 
Report.” Alternative the student can select to see only the “Ground 
Forces Report” and continue with the program. 

Primary and essential 

R321 R3.2,.R3.3, R3.4, R3.4, R3-5, hor, Woo eieoeys Ih O.8, ROO, 
owl ie 1 1, R3.12, R3.13,,R3. 14, R315, R3elG, R317, R318, 
Rone, hore, R321) R322 2 ROMO eieenOmme nets 1), 
R10.14 


Use Cases: - 


Actor Action System Response 


Ik. This use case begins when student 


selects to load the CAMPEX 


Employment Module. 


yi Displays the initial screen of 
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CAMPEX Employment Module 


6). Selects “Continue” 
4. Asks student if he wants or does not 
want to see the Introduction Reports. 
3y The student chooses an option to 
continue: 


To see Introduction Reports, go 
to “Intro Screen” section 

To continue without seeing the 
"Introduction Reports," go to 


“Continue” section 


6. Displays Ground Combat Units as of 
Day 1 screen 
i. Selects to Continue 
8. Displays the ATO Management 


screen 


Alternative Courses: - 
Section: Intro Screens 
Typical Course Events 
Actor Action System Response 


JU Selects to see “Intro Screens”’ 


ny: 


Ze 


14. 


16. 


18. 


Selects to Continue 


Selects to Continue 


Selects to Continue 


Selects to Continue 


Selects to Continue 


Selects to Continue 


Selects to Continue 


Selects to Continue 


Selects to Continue 


i 


hey 


se 


Ly 


1,0) 


Gets all the Introduction Reports 


Displays "Read me file for 


CAMPEX Employment Module" 


Displays the "Execute Order" 


Displays "DIA Intel Update" 


Displays "Thai Forces Available" 


Displays "Weather Report " 


Displays "Navy Update" 


Displays "Weapon Availability 


Update" 


Displays "Program Notes" 


Displays "Bomb Damages 


Assessment and Target Definitions" 


Section: Continue 


21. Displays "Analysis and Corrections" 


Typical Course Events: No additional events 


USE CASE (U2): STUDENT INFO 


Actors: 
Purpose: 


Overview: 


Type: 


Cross References: 


Section: Main 


Typical Course Events 


Student 

Student identifies himself 

Student inserts his personal information in the CAMPEX. If he has 
already entered his personal information just selects his own name. 
Alternative he can change his information. 

Primary and essential 

Reiko 3, Kil 4) Rida ).6, Riley, R10.11, R10.12; 
R10.13, R10.14 


Use Cases: “Start Employment Module” Use Case (U1) 


Actor Action System Response 


1. This use case begins when student 


selects to identify himself to execute 


an exercise 


i Presents available "Student" options 


I APs 


3 Chooses: 
Select an "Existing User Name," 
pometommescicct) Existing User” 
section. 
Enter a "New User," go to “New 
User” section. 
"Change Student Information,” go 
to “Change User Information” 


section. 


4. Presents CAMPEX Main Menu 


screen 
Section: Select Existing User 
Typical Course Events 
Actor Action System Response 
1. This use case begins when student 
selects "Existing User" 
2 Presents available students’ names 
3 Chooses his name 
4. Creates the selected student 
instantiation 


rs 


Section: New User 


Typical Course Events 


Actor Action System Response 
This use case begins when student 


selects "New User” 


Z Presents user input screen 

The student enters requested personal 

information 

Select to "Return" 
3). Stores student entered information 
6. System returns student to previous 


GUI from where student can follow 


the process of section "Existing 


Student" 

Section: Change User Information 

Typical Course Events 

Actor Action System Response 
1. This use case begins when student 
selects "Update User Information" 
2 Presents the selected user 

information 
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3. _—~‘ The student inputs his new 
information. 
4. Select to "Return" 
3. Stores student entered information 
6. System returns student to previous 
GUI from where student can follow 


the process of "Existing Student” 


section. 
USE CASE (U3): LOAD AN ATO 
Actors: Student 
Purpose: Load an ATO 
Overview: Student selects an ATO. With completion student is entered to 


"Main Menu" and the selected ATO is loaded. 
Type: primary and essential 
Cross References: R4.1, R.4.2 
Use Cases: Student must have completed the 
e "Start Employ” Use Case (U1) 
e Student must already entered the ATO that wants to 


load 


Section: Main 


Typical Course Events 
Actor Action System Response 
i This use case starts when the student 
selects to "Load an ATO" 
2 Selects an existing ATO from the 
list. 
3. Creates and updates the necessary 
objects of the selected ATO 
S) Select to continue 


4. Displays the "Main Menu" screen of 


ATO Employment Module 
USE CASE (U4): MANAGE AN ATO 
Actors: Student 
Purpose: Mange an ATO 
Overview: Student selects to manage to an ATO. With completion selected or 


new ATO information should be in CAMPEX Employment 
Module. 

Type: primary and essential 

Cross References: R4.1, R4.3, R4.4, R4.5, R4.6 


Use Cases: Student must have completed the 


e "Start Employment Module " Use Case (U1) 


e "Student Info" Use Case (U2) 


Section: Main 
Typical Course Events 


Actor Action 


1 Chooses one of the "ATO 1. 


Management" options. Student 
selects 
"Start a new ATO from 
scratch," go to “Start new ATO 
from scratch” section. 
"Erase an existing ATO," go to 
“Erase an ATO” section. 
"Copy an ATO to a new file, 
load new," go to “Copy an 
ATO” section. 


a Continue with program 


Section: Start anew ATO from scratch 


Typical Course Events 


ey 


System Response 


Displays the ATO Selection screen 


Actor Action System Response 


i Selects Start anew ATO from 
scratch 
2. Asks to enter the new ATO 
information 
Sy Input the new ATO information 
4. Stores the new ATO information 
Section: Copy an ATO 
Typical Course Events 
Actor Action System Response 
IL. Selects Copy an ATO 
i Enters the new ATO name 
5) Creates necessary ATO objects 
4. Selects an existent ATO 


3) Updates the entered ATO to the 


selected ATO information. 


Section: Erase an ATO 
Typical Course Events 
Actor Action System Response 


l. Selects Erase an existent ATO 


De Selects an existent ATO 


a Deletes selected ATO File 
information 


4. Displays the "ATO Selection" screen 


USE CASE (U5): DESCRIBE THE 20 TARGETS WITH HIGHEST PRIORITY 


Actors: 
Purpose: 


Overview: 


ype: 


Cross References: 


Section Main 
Typical Course Events 


Actor Action 


Student 
Fill the list with 20 targets with highest priority 
Student has decided which targets of his plan have the highest 
priority. Student edits the list of 20 targets with highest priority. 
After the completion of this use case the student’s "20 Highest 
Priority Target List" can be displayed by the application. 
Primary and essential 
Reale Ro-2; R5.3, Ro 49R10.2, RIO, Riles RO Osi4 
Use Cases: Student must have completed: 

e "Start Employment Module" Use Case (U1) 

e "Student Info" Use Case (U2) 


e "Load an ATO" Use Case (U3) 


System Response 


1. This use case begins when student has 


already decided about the 20 targets 


with the highest priority 


2. Student selects "Top 20 Targets" 


3. Displays the current list of top 20 


targets 


4. Student chooses a Priority List place 


5. Displays all targets 


6. Student select one of the displayed 


targets 


7. Updates targets priority 


If the target is already in the list then the program doesn’t accept the selection and 


displays message to the student to select another Target. 


USE CASE (U6): PLAN AN ATO 


Actors: 
Purpose: 


Overview: 


Type: 


Cross References: 


Student 

Enters student’s plans 

Student enters new missions, or edits old missions, or erases 
missions. With completion of this Use Case the student’s plans 
have been entered. 

Primary and essential 


Regie sO 5-7, 5:8, R5.9, R5.10, R10.2, RO Me R10. 12, 
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R10.13, R10.14 

Use Cases: Student must have completed: 
e "Start Employment Module" Use Case (U1) 
e "Student Info" Use Case (U2) 


e "Load an ATO" Use Case (U3) 


Section: Main 
Typical Course Events 
Actor Action System Response 
1. | This use case begins when student is 
ready to enter his plan in the 
application 
2. Student selects: 
"Plan an ATO," go to “Plan Edit 
Mission” section 
“Cancel a Mission or a Package of 


Missions,” go to “Cancel a 
Mission or a Mission Package” 
section 
oF Return to Main Menu screen 


4. Displays list of missions or packages 


of the selected by student type 
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Section: Plan or Edit a Mission 


Typical Course Events 


Actor Action System Response 
1. Student select to Plan or Edit a 


Mission 


No 


Displays the available options that 
user can see the lists of existent 
Missions. 
3. | Chooses one option 
4. Displays list of missions of the 
student’s selected type 
5. Selects to Enter or Edit Mission 
6. Asks from the student to enter a new 
mission number or to select a 
mission from the list to edit 
7. Student enters or selects a mission 
8. Displays an input form for the 
entered or selected mission 
9. Enters the mission’s information 
10. Exits from the form 


11. Enters new mission information to 


the system 


Section: Cancel a Mission or a Missions’ Package 


Typical Course Events 


Actor Action System Response 


ie Student selects to Cancel a new 


Mission or a Mission’s Package 


2. Selects an existent mission or 


package to cancel 


3. Deletes selected mission or package 


of missions 


USE CASE (U7): FLY AN ATO 


Actors: 
Purpose: 


Overview: 


Type: 


Cross References: 


Student 

To execute the planned missions 

Student is running fly missions. System calculates the result of the 
planned missions. Saves the results in a new ATO. Loads the new 
ATO. 

Primary and essential 

Rowley Noe, RO, Roa ROO. RIO 2) RIO 11, RIO Zsa 
R10.14 


Use Cases: Student must have completed: 
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e "Start Employment Module" Use case (U1) 
e "Student Info" Use Case (U2) 
e "Load an ATO" Use Case (U3) 
e "Plan an ATO" Use Cases (optional) Use Case (6) 
Section: Main 
Typical Course Events 
Actor Action System Response 
1. This use case begins when student has 
finished his plan editing 
2. Student selects "Fly ATO" 
2. Calculates the results of the planned 
missions 
4. Creates anew ATO 
5. Saves the results of the calculation to 
the new ATO 


6. Loads the new ATO 


USE CASE (U8): INITIAL INFORMATION 


Actors: Student 
Purpose: Inform student for the initial data of an ATO 
Overview: Student asks for initial information. With completion of this Use 
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Case the student has seen or printed the information that he has 
aSked for. 
Type: Primary and essential 
Cross References: R71 R72, R73, R7.4, R7.5, R7.6, R7.7,aR@ 3eR7.9, R7.10, 
R10.2, R10.11, R10.12, R10.13, R10.14 
Use Cases: Student must have completed: 
e "Start Employment Module" Use Case (U1) 
e "Student Info" Use Case (U2) 
e "Load an ATO" Use Case (U3) 
Section: Main 
Typical Course Events 
Actor Action System Response 
1. This use case begins when student has 
loaded an ATO or in any moment of 
the program 
2. Chooses to see actual data by: 
“Flights without Sorties” 
“Daily Summaries” 
“Logistic Requirements” 
“Blue Basing Summary as of Start 
of Current Day” 


“Sorties Available to Task at 


Sis) 


Airbases”’ 
“Analysis” 
“Recce for Targets at Start of 
Current Date” 
2). Calculates data to create the report 
4. Displays the selected report 
5. | Chooses one option: 
print report, go to “Print Report” 
section 
exit 


6. Displays the Main Menu screen 


fe Displays Main Menu screen 
Section: Print Report 
Typical Course Events 
Actor Action System Response 


1. Selects "Print". 


Zz Prints the displayed report 


USE CASE (U9): ESTIMATED RESULTS 


Actors: Student 

Purpose: Display the estimated results by the student plan before these plans 
execute 

Overview: Student asks for the estimated results. With completion of this Use 
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Case estimated results are displayed on the screen. 
Type: Primary and essential 
Cross References: R8.1, R8.2, R8.3, R8.4, R8.5, R8.6, R8.7, R8.8, R8.9, R8.10, 
R8.11, R8.12, R8.13, R10.2, R10.11, R10.12, R10.13, R10.14 
Use Cases: Student must have completed: 
e "Start Employment Module" Use Case (U1) 
e "Student Info" Use Case (U2) 
e "Load an ATO" Use Case (U3) 
e "Plan an ATO" Use Cases (Optional) (U6) 
Section: Main 


Typical Course Events 


Actor Action System Response 
1. This use case begins when student has 
finished (editing) his plan editing 
2. Student selects "Estimated Results” 
a Displays the available reports that 
user can See the estimated results 
4. Chooses one option 
3. Displays report of estimated results 
6. Chooses available options 
Selects “Return” 


Selects “Print’,-go"1o the ‘Pines 


Nee 


section 


10. Displays Main Menu screen 


Section: Print 
Typical Course Events 
Actor Action System Response 


he Selects “Print” 


bo 


Prints the displayed report 


USE CASE (010): ACTUAL RESULTS 


Actors: Student 
Purpose: Inform Student for the Results Reports of an ATO 
Overview: Student asks for Information. With completion of this Use Case, 


the student has seen or printed the information that he has asked 
for. 

Type: primary and essential 

Cross References: R9, R9.1, R9.2, R9.3, R9.4, RO.5, R9.6, RY.7, R9.10, RY.11, 
ROMO eel? 14, R9.15, R916, R917, R918, R919, R9.20, 
ROD Ty Roe 32 R924, R9.25, R9.26, R927, R10.2, R10.11, 
R10.12, R10.13, R10.14 
Use Cases: Student must have completed: 

e "Start Employment Module" Use Case (U1) 


e "Student Info" Use Case (U2) 
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e "Load an ATO" Use Case (U3) 
e "Fly an ATO Missions" Use Case (U7) 
Section: Main 
Typical Course Events 
Actor Action System Response 
1. This use case begins when student has 
flown an ATO and at any other 
moment of the program after that 
2. Chooses to see actual data by: 
“Cumulative Summary During the 
Previous Date” 
SCiment Recce: 
‘Enemy Over Blue Bases”’ 
“Ground War Summary” 
“Measures of Merit” 
“Yesterday Looses by Task Type” 
“Yesterday Looses by Aircraft 
Type” 
‘Final Target Status” 
oy Calculates data to create the report 
4. Displays the selected report 


5. | Chooses one option: 


eae, 


print report, go to “Print Report” 


section 


exit 


6. Displays the Main Menu screen 


10. Displays Main Menu screen 


Section: Print the Report 


Typical Course Events 


i Selects "Print". 


Actor Action _ System Response 


pA Prints the displayed report 


USE CASE (U11): MAP 


Actors: 
Purpose: 


Overview: 


Type: 


Cross References: 


Section: Main 


Typical Course Events 


Student 
See the map of the exercise area 
Student selects to see the map by Main Menu. With completion 
map 1s displayed on the screen 
Primary and essential 
R10.2, R10.3 
Use Cases: Student must have completed: 
e "Start Employment Module" Use Case (U1) 


e "Load an ATO” Use Case (U3) 
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Actor Action System Response 
1. This use case begins when student 
selects from "Main Menu" screen to 
see the "Exercise Map." 


Ds. Displays the Map on the screen 


USE CASE (U12): SEND EXERCISE 


Actors: Student 
Purpose: To send the results of an exercise to “Air University" 
Overview: Student must be connected to the "internet" first. Then, he selects 


Option of CAMPEX "Send Exercise Results to the Air University" 
and selects an exercise from the displayed. With the completion of 
this use case the selected exercise results are been sent to the Air 
University server. 
Type: Primary and essential 
Cross References: Re R22 R23, he es 5 
Use Cases: User must have completed the 
e "Student Info" Use Case (U2) 
e User must have connected to the Internet 
Section: Main 
Typical Course Events 
Actor Action System Response 
1. This use case begins when student 


14] 


decides to send the result of his 

exercise to the server of Air War 

College 

Connect to Internet 

Selects "Send the Result to the Air 

War College” 
4. Collects the necessary information 
5. Sends the necessary Information to 


Air College Server 


APPENDIX B —- SYSTEM SEQUENCE DIAGRAMS 


SELECT STUDENT 


Select “Student Services’ ) 












smutStudert Services GUI:Sampt 
8 Repeated for all 
i || st= getStudent( ):Studert Sbadents 
selec Student(N ame) we | : 
$= select Spadert (SSN): Sampt 
St= getSnadert Selfwith selection = 
GUI maps Spadet Yes): Student 
names to SSN 
update Sbaderit(st No) 
st’? = get Soadert(S SN): 
Spadert 
update Shadertt(st’ Yes) 


Figure 43. Sequence Diagram “‘Select a Student”’ 
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ADD STUDENT 


Select “Student Services’T ) 


smittadert Serves GUL Sant 


boput Stadent(SSNyank , 
firstName, stNme, country, 
address, e-Mfail, section) 











addStudert(S SN rank 
frstName, lastName 
country, address, e-hfal, 
section) 


User exters Stade 


Figure 44. Sequence Diagram ‘‘Add Student” 
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START EMPLOY 


1 Select “Continue with 
breroduction Repatts"t ) 


. 
Pt Ce re 


Select “Contirme with Ground 
Coubat Units as of Day]”() 





mee 
aire poss” M 


T= ceateReport( “Ground Ubuts”): 
Report 


Cece] Coles overs 500000000000000000000090 000080500008 84000 OF 058 TERRE Hens eCls BOECESESOSTOON seh cocceee” 


“Dephymant Hoduk” m tte 
moxt docign phar 





Figure 45. Sequence Diagram “Start an ATO” 
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SELECT ATO 






Select “Change ATO’1) 
s=mutdelectATOGUI: Sant 
st:= getSudent(selection=Yes ):Sbuderd 
oS cee le. 
Res Ul Panenvetseammnenmre tr cay ancy rae r _ a 
Select m ATO (descrption day iufowano, M ofA10a 
rr SO = 
descrption, diy): Sampt 
adl:= getAT ODaySel (rth 
selection =yes) : ATODay 
updateAT ODay (ad! , No) 
ot:= getSbudent (SSN) : Studert 


a= getATO (st, description) : ATO 


a2 := get AT ODay (a, day) : ATODay 


wpdateAT ODay (a2 Yes) 


Ct ot Ct Ee at oy 






aid day) :ATODay 


delete Group( add) 


| | delete Texadd) 
| | deleteSector(ud3) 


delete AT ODay (ad3) 





e 
000000 0000044 800 09 00 0000000 0000000 80000 FEOF EE CO OSOES OO 2T00 00008 FONE TID S EES DOCSTOC Ce HHer 8 C0088 


Figure 46. Sequence Diagram “‘Select an ATO” 
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NEW ATO 


s: Student <GUI ‘Application 
Select “Change ATO’Y ) 


Select “To enter a New 
ATO’() 
s:=mitSelect ATO GUL:Sapt 
St= getSpaderd(selection=Yes ):Snudert 


Input ATO Infommation 
(description) 
add ATO (st, description) 
add ATO (st, desaption) 
a=2etAT O(st, description) :ATO 
addA T ODay (2, with day=1) 


ad:=zetA T ODay(a, vith day=1) 
‘AT ODay 


oe 0000000008 0CCe CORTES O00 O1ASO00S 00000000009000 00000000 000 00000 B9008 00800000 0004 sooneen 


bapentsntCorp | 
add Group (ad, g) 


Benn] mo] c00ce 000000 00 00 00000 00 8000 00 0002007009 068 0481 Daneel 2000 290080 2008 Sos BOSTON S OO EOTecgeors” 


: Pea aie eee lee . 
lapentona facia | 
i | jaddSector(ad 5) 








Rone oe Ce rrr roe of Sr 





addT gt{ad ) 


Figure 47. Sequence Diagram “New ATO” 
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COPY AN EXISTING ATO 


Select “Change ATO'L ) 







Select “To copy am ATO’LT} 








¢:=mrCopyATOGUL:Sapt 
sti= getSpadent(selection=Yes ): Snider 


strecneeeh oP eceeenconsncncnecncanennenccueyssnasenecasenenseecen cetenenensasenscsenseess ceed oP oseass ‘ . ported forall 
: Stators t ATO 


al:= getAT Ot): ATO 


° 


° 
° 
< OCC OM © 000000008 000 0G20 00 04200 00 F800 000000009 SNF 0 O8S 0000000000 00008 Co SOOO OOERERESS Co Mem ecen of 


Soden tATO 


ry . 
. . 
eo. a - 
© © 00000+] 0 0 000000002 0000000000 0000000000 0000000000 0000000000 e ced ecc nas coccegeeeeoonneseesel col cece” 


200088 0000] o Of oon 000000 00008 00 448 OH ER TOS 0558 H90H88 N08 N 002 CBOE ehedS CESS FES e0SSER NS CORSO SESE] + Ol eee ccneeee” 


“New ATO” (description) 










add A TO(SSN, descriptionl) :ATO 
a=getA TO(st desamption!):ATO 


a’:= getATO (st, desamption2): ATO 
ad’: =getAT ODay (a’): AT ODay 


jean 
oF a 
add A T ODay (a, ad’ day): AT ODay 


eemrccetetoonary 





ad:getAT ODay (2, ad’ day): AT ODay 


Port or See ee ee rr oo ey 


Rapeatérall Mss 
ofiad : 





2000000000] co] + 00008000 00008 0000000008 09 0005+ 00000000000 009S00 900009000000 0000098902 0ER OOO DEF eFes Seeeee eels cote” 


Figure 48. Sequence Diagram “Copy an Existing ATO” 
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ERASE ATO 


Select “Delete an ATO’L ) 


Select am ATO to Erase () 





:GUI 


s=mitCopyATOGUI:Sampt 


eraseATO (SSN, description): 
Sapt 


lication 


stl:= getSpidert(selection= Yes ): Stade} 





eone ~ Rede Oe n C0CA COT EOs HHODsOOOONOE HOD EE SOO EESHO EES On CORES 


al = gtATO(stl)ATO 





st:= getSbadent (SSN) :Soadent 


a= getATO (st, description) :ATO 





~~ Bg watdforzall 
Stade ntet ATO 








ee 
PM Oo rr tor rr ries] Or 


. 
eeccgccoee 00 0 Ot 044 440046 00 00.08 6900 0090 0649040900000 400000 O0 000640 240 OF ODS EndootEr Oot este! eccccceres® 


mecccosesese: 00000640 O00 0 004 C00 00000 000 $4 00 0000000000089 04200 00000 000 CDC C0s SeseneesOOOO ry: eo BOSETOGOCCEOOOR 
. 





ad:= get TODay (a day ) 








delete Group (a4) 


00090 000 00 08100 00 1a80 00 SFn OOS 008 00008 FOr On nn ca 0000688 COD Ets oe Ot eese Hen EE eeEE 






delete Tat (a4) 





delete AT ODay (a day) 






deleteATO (st description) 







Rajoatd fralATODys of a 


moe BE nE ODO FRO 000 44 O04 9880 COOFTES CODES HOOD OS ETED NOSSO SEDER OO OOS COD ETOETHCON ITE ys Me enecooeny 


moe 2965008 H FOCUS EON COST SON EE HOEEE HSOH CEESHOOEE CESEDEE 04 O0ES O85 SPEED SED ESE ET CEE STEE eeneensecy, 


Rapbatid forall Misia of ad 


seee: 000000 0600 08 008 Ot 890 69 002 09 00000000000 O09 04 00044 C0 ORT OERS eeesecececegocce® 


Figure 49. Sequence Diagram of ‘Erase an ATO” 
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20 TARGETS WITH HIGHEST PRIORITY 


1 Select 20 Targets with 
Highest Prionity’{ ) 


s:=mitdT gsHichest Priority 
GUL:Samt 





stl = getSpadert{selection=Yes ):Study 


al:= get ATO(st]):ATO 


PEs 2) Co eo ot oe 
ry 


adl:= get AT ODay(al):ATODs 


© BO008e HF] oo 0p 00 0000000009 00C0 ee o0dd 200008 O0 00000000005 9009 00000H 20950 ed Op 80 nll ln ty CO NtES Om oMeoee 


t= getTezt(ad]) Target 





a3:= get AT O(st] selection=Yes):ATO 





add: get ATODay(ad selectim= Yes) 
-ATODY 


SOLOS” OOo of 08 08 00 00008 0899S SES eoCe ES eSEEESF CODECS OHS SORES OTT ES SEES Se BF S000 SeCR C000 BHOdThD Bo MSs gtetcceces cocer 
e 


t2:= getTzt(ad? pronity<0)-AT ODay 


modify Tet (SSN, description, 
day, tetNtr, pronty) ‘Samp 





st:=get Student (SSN). Sudert 


Posttoncomertd ® 
jony a=eetAT Ofet, description): ATO 


ad =getATODsy (a, dey: ATODYy 


update Tgp (ad, tetNor pricraty):Target 


Figure 50. Sequence Diagram “20 Highest Priority Targets” 
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PLAN ATO ENTER A NEW MISSION 


:GUI : lication :Database 


Select “Plm Edt Myxrsices’T ) 
$:=mitPlmEdrhio GUI:Saipt 

st:= getSnidert(selection= Yes ): Sbaders 
a= getAT Ot, selection=Yes):ATO 
ad := getAT ODay{a,sele ction=Yes):ATO 

Input Béission Infomm ation 

(MismNbtr, TaskType, Act Type 

Base, Sector, Tet, Tot Category 

TeSubcategory, Bomb Type, 


NborOfSorties, Package) 


erderbdcn (st, a, ad, monNbr, 

task Type, act Type, base, 

sector, tetNbr, tetCatNbr, 
Labita + fhe onky tet SubNbr, ban TypeNbr, 


matd® zy all tte o thar : 
ame Nya nbrOfSorties, package) 





exist:checkhisniin): Boolean 


[exist] supdate Bion (task Type, 
act Type, base, sector, tgxNor, 
tatCatNbr, tgtSubNbtr, 

bom TypeNbr, nbrOfSoarties , 
pack age) 


(Not exist]:addBdsnf(ad, RismNor, 
Task Type, Act Type, Base, 
Sector, Tet, Tg Category, 
TetSubcategory, Bomb Type, 
NorOfSorties, Package):Biission 


Figure 51. Sequence Diagram “Plan or Edit Mission”’ 


[a 


CANCEL MISSION 


rar 


hication :Database 


Select ‘*Camncel Biission or 
Package’ 


Stl:= getSoadentiselectuom= Yes ):Snad 


Bee tReet teen Bane ea ae 08m conn ee enn Onn Bonne O88 886 mem eeee te Sees HS eee seeee seeseee eee 


eee One e ee ene es Onn e eR On ee eee EERE EEE eee Ee Eee EE 


m:= getBisn(ad]).Bissiacn 





Seeee el =a enn onmeemecece te nnn en Ohh n eeceeee te teeeesh OF Ons ene ceeeeeeees cone es cess secer+oo-=afooleo~ 
: 
Secev econ | anf ee nen een an nae n enn nan 00 wend monn omen name Sen OO0e Sm messes cennnenetesensscennen =eapuefoccenerecccee’ 


Peeeeetetren tr pirrerrrrorrrr i errr tre rir rie errr iitiietrerrrr fr  ttierir rr TS iii 


Select “‘hdassionto Delete’’ 
QA4smNbor) 


deletehIiow(SSN, desarption, 
day, BismNbr):Sanipt 





st:= get Souder (SSN): Spader. 
ad:=eet AT ODay (a, day): ATODsg 





Figure 52. Sequence Diagram ‘‘Cancel Mission” 


CANCEL MISSIONS OF A PACKAGE 


:Database 


Select “Carel Bilission aor 
Package’ 


$:=mutDelete Package GUI: Sappt 


stl:= getSnidertiselection=Yes }:Sniderp 


Serecccenas coccce een cece c- ane 


Bait Staisatislavasstesedssi sated —- wisi ETEATO 
al:= geetATOGCtl):ATO entices ee Sradlo nt st 


PO errr rrr rrr rrr 


= O00 00 00 0 00 ce een n Conon nse en CHae een Onn Cre enee Here SEE nSenenmeneseceweetnseenne 


Ptr 


se coceen- aa — F 
WAL:= ELATODyfa1 ATO 





Doce cclelenet 6 Ot comeccecets ccte ct teccces 
Sees cn eee, Pee ee errr rr rr irr ir eo etoeseeneee® 


Scconsaccece| See ee eee ir tri tir tii irri meeceeceeeescooe® 


Select “Package to Delete’’ 
(pack age) 





delete Package(SSN description 
Alay, m package }: Sampt 





$t:=get Soudert (SSN): Moadert. 
a:=eetAT OG, desaiptian): ATO 


ad:=getAT ODay (a, dey): ATODsy 


Fepeand forall 
Myswrm of ad that 
have ths p ha 5 


mac ceccce 





Figure 53. Sequence Diagram “Cancel Package of Missions” 
bo2 


FLY ATO 


s: Student :-GUI :-Application :Datahase 


Select “Fly ATO’T ) 
fy ATO () :Sampt 
PL:= getSmudent(selection=Yes ):Spadert 
a:= ger A TOCt, selection=Yes): ATO 


ad:= getAT ODay{a sele ction= Yes): ATO 
deletehismBad(ad, with nbrOfSorties=0 
Or Task Type= 0 Or ActType=0 ) 


For all Bad Meri of ad 


eo osean 





up date Group (ad’ , m group , 1) 
update Sector(ad’, m sector, l) 


update Target(ad’, mte¢t, 1) 


e 
e 
Pee TOT Ee ETT OTererri errr rier Tiere rier err Tie rir irre rie iii ei rery a) Cr 


Foraell Kies wns of ad 


Figure 54. Sequence Diagram “Fly an ATO” 
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ESTIMATED RESULTS 


s: Student 





Select ‘*Estnmated Resuls’’(Q) 






st:= getSbdadertiselection=Yes ):Stiden 
a= getAT O(st, selection=Yes):ATO 





pd := getAT ODay(e,sele ciom=Yes):ATO 


ri=cte ate Report (ad, ‘‘Estrmated 
Results’’): Report 


a2 eee caccaccccacas caccccacacaagecccacaacacaccgsooesseeececseetacscacassaccaacaad + aa-s, 


m:=gethisn(ad): Biission Bem pean fox all 
hixcwrm of ad 
er:=cal culate EstaumatedResultsimn): 
it .array ; 


update Report(r, rm, er) 


ee as + a seaaas am > sa0 + cane aceauas caccaccacacccaccccacccacccacaas cacacsccacseatassaaas|«+§-ccet 





Figure 55. Sequence Diagram ‘‘Estimated Results’”’ 
MISSIONS WITHOUT SORTIES 


s: Student :GUI : lication 


Tep :=fhetts WirhoutSortues ( } 
:Sapt 






st:= getSnadert(selection=Yes }:Spadent 
a= gtAT O(st, selection=Yes}:ATO 





ha:= get AT ODay(asele ction=Yes}: ATO 


r-=cre ate Report (ad, “Fligtts 
Without Sorties’?}: Report 
ea 
m= gethien(ad, wrth sorties=0): Rete eral 
¢oTtms 
2 date Report(r, m) : 


Ole sh ae +00 00000000 0000000 00 a0 ad aban aalan aa Gan tat Caan cahat canon ocacaabaaalOOe COanatataad + mp ateaace 


Figure 56. Sequence Diagram ‘“‘Flights Without Sorties”’ 
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INITIAL INFORMATION - DAILY SUMMARY 


s: Student >GUI :Application :Database 
Select “‘Daily Summary” 0 
rep :=daitlySiammary O:Sarpt 


st:i= getSpident{(selection=Yes ):Spidert 
ai= getAT O(st, selection= Yes): ATO 
ad:= getA T ODay{a,selection=Yes):ATO 


T:=cre ate Report (ad, “Daily Summnary”’ 
): Report 


eee 


Kopoatd forall 
Mis ps ofad 


update Report(r, m) 


Figure 57. Sequence Diagram “‘Daily Summary” 


INITIAL INFORMATION — LOGISTICS REQUIREMENTS 






s: Student :GUI : lication 
| Select “Logistics 
Rea emery 770) 
rep :=Logistics Requirements ( ) 
‘Saypt 


St:= getSnidert(selectiom=Yes ):Studert. 
a= getAT O(st, selection= Yes}: ATO 





ad:= getA T ODay{a,selectiom= Yes): ATO 


T:=cte ate Report (ad, ““Logistic 
Requirements”’ ): Report 


m: =gethdsn(ad): Béisacn 





Fa poatd forall 
Mxciom of ad 


r= calcLogReq@n):it.aray 


update Report(r, m, Ir) 


Figure 58. Sequence Diagram “Logistic Requirements” 
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INITIAL INFORMATION - BLUE BASING SUMMARY 


s: Student 






| Select ““‘Bhie Basing 
Summnary”’O 









rep :=blueBasmg Sumo: Sapt 


i eetAT O(st, selectio=Yes):ATO 





= getAT ODayfa,selectiom=Yes):ATO 
T:=are ate Report(ad, “Bhie Basinz’”’ 








Figure 59. Sequence Diagram “Blue Basing Summary” 


INITIAL INFORMATION - “RECCE FOR TARGETS” 


s: Student :GUI :Application 


Select “‘Recce for Targets”’O 


rep :=recce Tate ):Sapt 
st:= getSpident(selection=Yes ):Spadent 


ai= getAT O(st, selection= Yes): ATO 
ed:= getA T ODay(a sele ction= Yes): ATO 





T:=cre ateReport(ad, “Recce Target 
of Day’’): Report 


Ce oe Sr er oo 


=getTg(ad): Target : 
ans 


updateReport(r, t) 


. 
brtion OP Pr rir iri iii On Sirs 


Figure 60. Sequence Diagram ‘“‘Recce for Targets’’ 
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INITIAL INFORMATION - “ANALYSIS” 


s: Student :GUI -Application 
Select. “Analysis” 0 
rep :=analysis( ):Sampt 


st:= getSoidert(selection= Yes ): Snidert 
ai= get AT O(st, selection=Yes):ATO 

ad:= getAT ODay{a,sele ction= Yes): ATO 
T:=cre ate Report (ad, “‘Analysis’’): 


Senene 
ama‘= calculate Analysis@n): it.array 


updateReport(r,m, ana) 


POPP ie iii ry 


Figure 61. Sequence Diagram ‘‘Analysis” 


INITIAL INFORMATION - “SORTIES AVAILABLE” 










s: Student :GUI : lication :Database 


Select “‘Sorties Available’’O 
Tep '=sorties Available ( }: Sagpt 
St:= getSoiderti(selection=Yes ): Student 
a= getAT O(st, selection=Yes): ATO 
ad:= get AT ODay(a selection=Yes}): ATC 
r:=cre ate Report (ad, ““Available 
Sorties”’}: Report 


PerPerret irri erieriiiiiitiiiiiiiitiiiiiiiiiiiiiiririitiieii irri ie ies 


as :=calculate Sorties Available fm f= 
): Integer 


updateRepart(r, g, as} 


7 
= a 
woe ORO eer Peeerre rir tet rerrr eee er ere ereererrrrrrrerrerrrrrrs | 


Figure 62. Sequence Diagram “Sorties Available” 
log 


Fepeandfrall 
Ms ¢2m ofad 


ACTUAL RESULTS - “CUMULATIVE SUMMARY” 


s: Student :Application | 


Select ‘“‘Sorties Efe ct” OQ) 
rep:=Cummualative Samy ):Sampt 
st:= getSnudent(selection=Yes ):Spudert 


a= getATO(st, selection=Yes):ATO 


ad:= geLA TODay(a sele ction=Yes): ATO 


T'=cre tteReport (ad, “Cunmalatrve 
Summary’): Report 


geccemccenens Or re oe rr 


ad? =eetAT Oday(a, with 
duy<=ad day): ATODay 






cs2:=caleulateCum SumP2(g): bt aay 


update Report(r, g, 52 ) 


oaneen 0060 000000000008 20000 Cees COO SOHO FSET ODO COEOTOE ODS DD AH Oe DEDD DODO OSEDODOTED COOD Seen I eC DI Decenee” 


Piet Ot De Po es ot Ps 


ti=getTgfad’): Target 
cs3:=caloulateCum SummP3(t):int aay 





updateRepcrt(r, t, 53 ): Report 


nconee PPP ee ee er Oo) 


Figure 63. Sequence Diagram ‘Cumulative Summary” 
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ACTUAL RESULTS - “ENEMY OVER BLUE BASES” 


s: Student :GUI : lication :Database 


] Select. “Enemy Over Bhie 


Bases’?O 

rep :=enexsy OverBhieBases( ) 

:Sapt 
st:= getSnident(Selection=Yes ): Studert 
a= get AT O6st, selection=Yes): ATO 
ad:= get AT ODayi{a sele ction= Yes): ATO 
T:=cte ate Report (ad, ““Exerry Over 
Bhi Bases”’): Report 


b=etBase s(ad) Base 


sone 
+ 


Eapeatd forall Bases of ad 
Teepe ated forall Group of b 


eobd :=caleulat eFremy OverBlieB : 
ases(t gz): btezger 


updateReport(r, b, g, eobb) 


Wecccans coces co Poobe coe ccccs coe scene F000 2000s +m OSES FSS HOSES OSHS FOS OSS One OOF 4s BASH EDS euaees seccceneseusesee* 


Figure 64. Sequence Diagram “‘Enemy over Blue Bases”’ 


ACTUAL RESULTS - “GROUND WAR SUMMARY” 


s: Student | :GUI : lication :Database 


| Select ‘* Ground War 
22219 Sl oR emer 
st:= getSpadert(selection=Ves }: Stadert 
a:= getAT O(st, selection=Yes}:ATO 
pd:= eetAT ODay{a sele ction= Yes}: ATO 
T:=cre ate Report (ad, “* Ground War 
Summmary””)}: Report 


PeOen er eereoroey 


$:=getSector(ad): Sector Bapeabd forall Secra 
of ad: 


Poeeeer errr eer rir iir Citi itr iteeeriiiiiir re tri irre iii tii itrrirte? ft rit tee = 


a a 
Wises 3» ofs 


weeeeereee 


$1:=calc Sectoritn): Rteger 


updateRepert(r, 1}: Report 


Prreerrrrre erie iri rirrir iri rr tii ririririiiiiriiriiiis of trriiiry 


OPIS Oe Peri irri riirir irri iiiriririiiiiy G6 Sires 


Figure 65. Sequence Diagram “Ground War Summary” 
Se) 


ACTUAL RESULTS - “MEASURES OF MERIT” 


Select “Ddeasures of Merit”) 
Tep:=mneasures Ofhfertt () :Sampt 


t= getStudent(selection=Yes ):Staderd 
a= get AT O(ct, selection=Yes):ATO 





d= getATODayra sele ction= Yes): ATC 
T=cre tteReport (ad, “Ideasures of 
Mert”): Report 


Mo, of Po ee eo oy. Poor ory 


r RED 


tothe ot Co ot 


ad’ =puLAT Odey(a, with dey =ad. || Usb ofa 


day+ land smaller than the user 
rput dy ): ATODay 


m’-=eet]Men(ad’): Missicn 





o1:=caloulate Over allindicator 


SQ, mn’): bt ary 
pdateReport(r, o1, m): Report 





BY Oo iii irr irri Cr erect hs 


00000000001 duml 009000000 00050 S0R0ccess ooceeete Fees ce ceees cee e8e8 t 8408000 008 808 ce ccteseesocccs tml seecescgcese ce” 


Figure 66. Sequence Diagram “Measures of Merit” 
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ACTUAL RESULTS - “YESTERDAY LOSSES BY AIRCRAFT TYPE” 


Select “Yesterday Losses By 


Arcat "0 


Tep=yesterdayLossesBy Actt ( 
).Sampt 


cond « TEgAdTypeArcnh evesecel eofessesooescenes 
—_— 


0 «000000 000000009000 020000000 F0 FO 0000000000000 00 000 Onas CAF Fs BESO O ROSS ERON OO OtCCEED +o 0enn Gon, 











st= getSpudent/selection=Yes ): Student 
a= getAT Ofst, selection=Yes):ATO 
ad:= getAT Ofa selection=Yes):AT 0 


T=ceateReport(ad, “Yesterday Losses 
By Amcraft Type’): Report 


m=getho(ad, with acftType = 
act ):Iission 


al? get TODay(a, with dey=ad. dy: 
1): ATODay 





m’=gethin(ad’, vithmanNb r= 
m mnNor) :hfission 


los :=caloulateLossestin yn’): bteger 


Ya 


updateReport(r, los, m ): Report 


Figure 67. Sequence Diagram “Yesterday Losses By Aircraft Type” 
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ACTUAL RESULTS - “YESTERDAY LOSSES BY TASK TYPE” 












s: Student :GUI 2 lication 
Select ““Yesterduy Losses By 
ieee Oo Tep '=yesterd ayLosses By Task 
Type ():Sampt 


Sti= getSpidert(selection=Yes ):Snidera 
a= get AT Ost, selectio=Yes): ATO 
ad:= getAT O(a selecticom=Yes):ATO 


r:=cre ate Report(ad, ““Yesterday Losses 
By Task Type’’): Report 


ee 


ee ee ee ee Ea peated forall Tad 
a TGR Al [ol [iu doe . ale 
m:=gethio ad, wah taskType = A 

Kapeand forall 

Maciomw 


tsk): Bilission 





ad’:=getATODay(a, with day—ad.day- 


1): ATODsy 

m”:=gethio(ad’, with mmNb r= 

m xmsnNobr) :Bfisaion 
los :=calculateLosses(Qn yn”): bteger 


az 


updateReport(r, los, m ): Report 


Faas 1 OME E990 0000 000000008 e Oo COST UH Veo OH ONaET O8000 0000008880" =800n= CESS OFA HOESSOREE: 


Neccovers eee ee ee ee em e PVCS TETEH Huet amen 


Figure 68. Sequence Diagram “Yesterday Losses By Task Type” 


MAP 


s: Student :GUI :Apphlication :Database 
Select ‘“‘BAaps”’ (3 


$:=mrSelecthiaps ():Saqpt : 
Select *‘Area biap’’() 


map := selecthiapGimspNbr ): 
Sapt 





Figure 69. Sequence Diagram of ‘“‘Map” 
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SEND ATO 


Select “Chinge ATO’t) 
Select “To send am ATO’T) 









Initialize “Send ATO GUI’ 
st:= getSpudent(selection=Yes ): Shuderd 


cOmacatoeua eaneccesecense oo + enreecomacagaene 





al:= getATO(st):ATO 


ie pes cae 
23 = & aya). eee 






ee 
ee 
eccccee CRE 0000000 000 00 0er TO RAO O cama eae hs ODES Caton banat aaHareoseeccenncenes connec celal col ecco” 


selectAT OToSend (SSN, 
description , description?) : Script | Jexist:check Student(SSN):Boolemn Kenudent east 
fexist]:add Student(S SN): Spadert corte with net 


st=get Snadert( SSN): Student. step 
a=getAT O(st description |):ATO 


a= getAT O (st, description2): ATO 








add AT ODay (a, ad’ day): AT ODay 
ad:getAT ODay (a, ad’ day): AT ODay 
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Figure 70. Sequence Diagram ‘Send ATO” 


163 


APPENDIX C ABBREVIATIONS ACRONYMS DEFINITIONS 


Transition from OLE of Microsoft 
Adaptability The ease with which software can be modified to 


meet new requirement [DODSTR 92, p.47] 







Cohesion The manner and degree to which the tasks | 





performed by a single component are related to one 





another | 






Coupling |The degree of data or contro] connectivity 





between different assets of a software system. 






Because coupled assets cannot be separated from 






each other easily and used alone, the scope of reuse 






iS Narrowed. 


2. The manner and degree of interdependence 





between components. 







DCE Distributed 


Computing 









Environment 
Distributed 
Component Object 
Model 





Four Generation 
Languages 


Interoperability Measure of the ability to share information between 






different systems. 


Operating System 


OEE Object Linking 





and Embedding 
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Reengineering The process of examining and altering an existing 
software component in order to reformat or 
| configure it. Reengineering is comprised of the 


subprocesses of reverse engineering, retargeting, 





restructuring, redocumentation, and _ forward 


engineering. 





Stub COM or CORBA Mechanism that allow seamless 
access to remote objects 


Air Interdiction Air operations conducted to destroy, neutralize, or 









delay the enemy’s military potential before it can be 
brought to bear effectively against friendly forces 


at such distance from friendly forces that detailed 





integration of each air mission with the fire and 


movement of friendly forces 1s not required. (Air 










War College Glossary.) 
















AWACS Airborne Warning 
and Control 
System 
BAI Battlefield Air BAI was a subset of Air Interdiction. Missions, 
Interdiction which are tasked against enemy forces, and/or 
resources that are in a position to directly influence 
and affect ongoing land operations, but which are 
not yet directly engaged in combat. These missions 
are included in Interdiction in the new AFM 1-1 
and BAI no longer is an Air Force mission. (Air 
| War College Glossary.) 
BDA Battlefield 


Damage 
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Abbreviation TUPGPGNT Explanation GI 





Control, and 


Communication 









Defense 





Communications 


Agency 


Defense The area EF-111 or Wild Weasel aircraft 
Suppression Area | employing stand-off Jamming or suppression would 
be responsible for negating enemy capability. They 


would not penetrate enemy territory. (Air War 


College Glossary.) 


Early Warning 


Forward Edge of The foremost limits of a series of areas in which 





the Battle Area ground combat units are deployed, excluding the 
areas in which the covering or screening forces are 
operating, designated to coordinate fire support, the 
positioning of forces, or the maneuver of units. (Air 


War College Glossary.) 


Offensive 
Counterair 


Surface to Air 
Missile 


SEAD Suppression of 
Enemy Air 
Defense 
pf Sortie In air operations, an operational flight by one 
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Abbreviation | Explanation 
——— aircraft. (Air War College Glossary.) 


UG Unit Type Code A five-character alphanumeric code that uniquely 
identifies each type unit of the Armed Forces. (Air 
War College Glossary.) 
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